Guild Wars Wiki talk:Builds/Archive 1

From Guild Wars Wiki
Jump to navigationJump to search


I'd really like to open a discussion in terms of Builds, as I see it's slowly creeping into topics such as Guilds and PvP, and it's slowly distracting from the original conversations. I'd also like to open a discussion unique to this website, I understand many of you are from GuildWiki, if you are, just be open to suggestions. Things like "I will not budge on my stance on builds" are not beneficial to an official wiki.

So builds:

I love builds, not only are they so important when it comes to PvP, (where it all comes down to your personal skill, team strategy, and build) but also in elite PvE areas such as Domain of Anguish where builds could be what gets you that Tormented shield. I think it would be detrimental to the official wiki to not include builds.

We can all agree that the vetting process is flawed, considering, I can get on msn and get 3 homeboys to vet a build. If it's the process that is flawed, please dont' jump to completely condemning any postings of builds, of any capacity, on the site. If the process is flawed, suggest a process. If you want an example of vetting process done well, check the GvG section on guildwiki. All builds there are used in GvG and HELP pvp'ers, as well as people looking to get into pvp. Just the other day I needed an Avatar of Melandru bar, guess where I looked. :) It would be a valuable resource to all players, both pve and pvp. If I need a Searing bar, I want to be able to find one, or if we're starting out gvg, and want to see what a top guild is running, I want to be able to find one.

Can we all agree that BUILDS WILL BE USEFUL to people visiting the site? and it's the implementation we'll need to be careful with. --Narcism 09:47, 8 February 2007 (PST)

There is a discussion started on this. It was slipped into the "Article Retention" Policy and can be found on that talk page here. Lojiin 09:55, 8 February 2007 (PST)

Might as well discuss it here

← moved from Project talk:Article retention

I'll make Karlos Nightmares come true by appearing here. ;-)

This policy is not a copy of the guildwiki one (as the summary states), the part about builds is markedly different. Doing away with a part of the (old) wiki that has a big percentage of the wikis articles, edits and page views(!) should warrant more discussion than simply the unmentioned altering of a few words while copying policy. From the discussion here I figure that there is at least one other part of the policy that is under discussion at the moment.

To make one thing clear: I am not a diehard build fanatic. If people can bring forward arguments why the build part of the wiki as it exists now should not find a place here, I am open for discussion. But discussion it should be, not discretion. --Xeeron 08:27, 8 February 2007 (PST)

Figuring that the discussion is going to run rampant eventually, I figure I might as well start it and hopefully lay some rational groundwork. I'm not a fan of alot of the arguments/debates that seem to go on about builds but I can see where the build section can be useful. Also, I think if the builds were left off the wiki another location would just spring up to house them so it may be beneficial to keep them here for simplicity purposes. IF that were to happen, though, there would obviously need to be a better vetting process and policy in place than the one that currently exists on guildwiki. As sort of a summery (my thoughts are quite diverse on the subject atm)...

A Few Points for:

  1. People find the information is useful. (Personally, I find at least the boss farming builds/lists handy)
  2. It provides a place people can bring up potential builds and get feedback on them
  3. People can look and see what the currently popular builds are. (e.g. I noticed someone on gwg asking what zergway was. If builds were hosted it could be found easily)

A Few Points against:

  1. Its a moderation headache. People get out of hand, can't take constructive criticism or can't tell when they're being insulting when they think they're offering criticism.
  2. Its potentially very messy which detracts from its usefulness.
  3. Its potentially biased. People can vote for or against builds on whim leading to complaints and flames. (see point 1)

Some, perhaps all I don't know, of the cons could potentially be addressed by a good builds policy. I.e. what can be posted, and what people should expect when posting a build. The question for me is, is the benefit worth the trouble. Lojiin 09:20, 8 February 2007 (PST)

The builds section doesn't work in the form that it was handled in the GuildWiki. Not allowing build articles is the easiest way to handle them, but we could try something else. A partner wiki for builds might work well. Linking to skill articles and other usefull stuff can be easily done in the following manner if people so wish: [[gww:Troll Unguent]] --Gem (talk) 10:03, 8 February 2007 (PST)
Might I ask in what ways that partner wiki would be different from guildwiki? We could incorporate those differences here and there would be no need for any split in wikis. --Xeeron 10:12, 8 February 2007 (PST)
I agree that the current guildwiki build section is essentially not functioning with the possible exception of _some_ of the vetted builds (e.g. the E/A;A/E Solo farmer and 55 builds). That being said I don't think the section should simply be dismissed on that basis, which isn't to say that it shouldn't be dismissed simply that I don't think that's a valid basis for doing so. I argue that the viability of the section should be considered from the viewpoint of the average end user. That is, is Joe Gamer who comes to the wiki going to find that section useful? And if so, what are the conditions under which it would be useful? My opinion is that the build section could be made useful. However, I think it would take an agreed upon policy and if such a policy could not be found then the viability of the section would be in question. Lojiin 10:14, 8 February 2007 (PST)
Warskull hit it on the head over on GWiki when he said that system works fine for any builds which have a clear metric for success (namely farming and running builds) but generally falls down in all other cases. I really like the builds section over there, its insanely useful, but I don't think any system here will be any better than what is over there. Oblio 10:22, 8 February 2007 (PST)

I'm fine with things that will be useful. I am sick of Joe Newbie posting his blood necromancer build. The E/A sliver guide is good. The SP A/Mo ganker guide is good. The bow elementalist that completed abaddon's gate with master bonus is not. People with no understanding of the game posting "their" build should not participate. How to fix this? Post only popular builds and let someone like Trevor (if he wants to) approve them. I, for one, am not going to lose sleep over being a week late in documenting "the next big thing". There should be tight restrictions on even starting a new page, for example Guild Wars Wiki:New build page proposals could comprise of a level 3 header with a title and profession indicator, purpose, a line of description and a line of why it should be given an article (and the name(s) of the people who will write it). I never want to see a 500-article category of poorly-written trash again. — Skuld 11:29, 8 February 2007 (PST)

Agreed, Skuld. I posted something similar below. LordBiro 11:35, 8 February 2007 (PST)
Agreed, I think you guys are on the right track. A similar idea would be to have a certain limit on the number of builds per profession, and have each allowed slot intended to fill a specific role. Then the community could discuss what the best version is, and it could be updated as new skills come out. For example, you'd have a "definitive ranger interrupt build", a "definitive elementalist nuker build" etc. This would be really helpful in directing new players to playing the right kind of build rather than thinking they can just make up whatever they want. Skuld's idea of needing to get approval on a proposal for a new build before creating it is also a good idea. This should also reduce ownership issues, since once the proposal was approved, everyone could then give their input on what skills should be used and the page would be created by the community much like an article. -- BrianG 19:25, 9 February 2007 (PST)

I was going to to vote FOR a builds section, because people do need advice on builds. The key word is ADVICE. A new necromancer should be able to clue in about how to use Spiteful Spirit to advantage, for example, with suggestions for secondary professions and synergistic skills; for the rest experimentation and creative combination is the best way to find something that works for that individual. As I was writing my argument, it occurred to me that the best place for build guidance might not be a builds section as such. There is already some general information on popular usage for particular professions, which could be expanded. Documentation on areas in the game could include information on how to approach builds for that area. But most importantly, the skills section itself is the key to the builds section. Instead of just documenting Spiteful Spirit, for example, in terms of what it does and where it's captured, also include some information on how to effectively use it as a base for build. What the point of the spell is, and what skills to consider combining it with to exploit its main benefit and add value. The value of a bar in a build page for me is the aha! factor: is THAT what that stupid-looking elite is good for! I feel own creative builds are more for a forum than a wiki, but I have no objection to a page which links to own creative builds that wiki contributors have made. This would make it clear that they are examples and not cast in stone and the only way to play that elite or that area.Humble Goshly 03:55, 18 April 2007 (EDT)

Completely new policy

The start of a new wiki is a chance to start a better policy as well. I designed the current proposal to allow everyone to have their build discussed here and get comments on it (in their userspace), while restricting those builds that Joe Normaluser sees to the ones that are ubiquitous in Guild Wars. Especially, there will be no rating of builds based on voting. --Xeeron 11:10, 8 February 2007 (PST)

This is better than most of the build policies I have seen, but it's still not good enough. I think builds should not have been implemented on the GuildWiki, and so I would say any policy allowing builds is going to have to be absolutely airtight for me to support it.
My first concern is that "Common builds always originate from private builds." This seems totally back to front to me. A lot of people on the GuildWiki have been working to avoid personal builds, and the recommendation was to move personal builds to people's user spaces, which is what I thought this policy was suggesting.
But as it is at present, if I want to document Touch Ranger then I would first have to produce a private build with that name. This seems wrong. It is not a build invented by me, it is a build that I have seen being used and have imitated.
I would say that the only policy I would consider supporting is one that simply says personal builds cannot exist outside of someone's user space. Even then I probably wouldn't support it. LordBiro 11:32, 8 February 2007 (PST)
I've thought of this wiki as a place far and away from the Wiki-drama we have on the GuildWiki. I would simply go for the builds that have been documented on the GW Website itself, and nothing outside of that. The builds-guru that I am, I am somewhat opposed to have it on this new wiki. Rapta 11:37, 8 February 2007 (PST)
The one big problem with you documenting the touch ranger in normal namespace is that is opens the door for all the bad builds and the selection problems we had on guildwiki. People can create all kinds of builds they want on their userspaces (even without this policy of the userspace policy is less restrictive), the point is in only allowing ubiquious builds (which can, for example, be seen on observer mode) into the normal userspace. --Xeeron 11:42, 8 February 2007 (PST)
Not even that is needed, in my opinion. Simply document the ones that are discussed on the Main website, such as the ones listed [1] here. Rapta 11:45, 8 February 2007 (PST)
Except scratch the "such as" and replace it with "only". =P I don't see the need to expand the Builds section here anywhere beyond that. Of course, I could host a builds section in my namespace, but either way, it's not too big a deal limiting our builds here beyond just those above. Rapta 11:48, 8 February 2007 (PST)
Two quick notes on that. 1. The article, and most other articles I've seen on the main site, are PvP oriented leaving no PvE builds. Which, at some point, I'm sure someone will complain about. 2. Any lists are likely not to include all the common/useful builds. The latter may not be a problem as the metagame changes will initiate changes in what's being used in PvP. The PvE note, though, is potentially debatable. Lojiin 11:50, 8 February 2007 (PST)
Well really, for example, skills that are found to be useful can just have a quick note saying "___ is often used in PvE to ____". Rapta 11:52, 8 February 2007 (PST)
True, but what about a 55 build? or would guides cover those? A guild to playing a 55 with example for each class. Or the common farming builds (E/A or A/E, 55 Mo, 55N, Me/N Mightnight farmer etc.) under a farming guide? Keeping those builds in a guides (and with the currently length of the E/A & A/E pages at least I could see them being made into guides with boss lists) type section would keep the usefulness of them while avoiding the issues that the current GuildWiki build section has. Lojiin 11:54, 8 February 2007 (PST)
I further agree with what LordBiro stated about this policy needing to be airtight -- being Guild Wars is heavily focused around strategy, with builds being a major component of that, it has potential to be one of the most troublesome topics on the site (much like it is on Guildwiki). I love the idea of being able to look up "common" builds here, but I don't feel that the statement "seen others play the build more than once in game" is restrictive enough. Unless a build is used and vetted by hundreds of players in game (e.g. minion master, 55-monk or necro, etc.) then we're still going to have more than we can handle on our hands. I believe we need to use something more along the lines of "extremely common" with a clear definition. --Zampani 12:02, 8 February 2007 (PST)
It's going to be extremely difficult to maintain any sort of builds section with the site right now. We would still need to get the skills down. In the meantime, I could always just pull some of the builds over on the GWiki and place it onto my namespace, since I have made such contributions to just about every single build in our tested section. The templates, however, should be brought over asap. — Rapta (talk|contribs) 12:05, 8 February 2007 (PST)


First, the reason I removed builds from article retention was simply to delay the process and allow us to figure out one better. I didn't want the builds section to start up immediately with the old GuildWiki drama. My intent was not to forbid them, and even if it was, I don't have the authority, even though sometimes it seems like people around here think I do. :)

I'd like to start out with a simple statement: there is no democratic builds process that can work on wiki. This is the conclusion I think nearly everybody got from the GuildWiki builds section. I don't think there's any shame in admitting it. Wiki isn't a democratic medium. We don't all have the same voice. For example, I, via force of personality and the respect many people have for me, end up having more say than an anonymous user. It might not be fair, but it's the way a consensus-oriented medium works.

I'd like to follow up with another simple statement: the wiki is not a research and development lab. That is, this is not the place for people to be coming up with new builds. The game is that place. The great builds run through PvP and are successful, and then they become noticed. Thus, we shouldn't be documenting any old build here -- we should be documenting the ones that are already vetted by the community via the process of PvP combat.

People who can separate "I think this build is good" from "the community recognizes this build as important" are rare. So rare, in fact, that I think the only way for a builds section to work on this wiki is for a council of PvP-minded players, ones that are in the fray and see what works, be in charge of writing and approving build articles.

Such a council would have a great responsibility—if one of their guilds developed a build that happened to win a couple games, that still doesn't make the build important to the community. I don't want to establish an R&D council. Instead, these guys should be able to look at the PvP scene, and say, "Currently, IWAY and MM builds are prevalent in GvG, so the typical builds of these types should be documented."

On the subject of userspace builds, well, I think those are cool. That's what userspace is for. However, the only reason a build should be moved out of userspace and into article space is if that build has become important, on an objective level, to the game itself. Do people need to know the build exists to PvP successfully? I can think of no better metric than that.

Tanaric 12:14, 8 February 2007 (PST)

the wiki is not a research and development lab <-- this is key. — Skuld 12:54, 8 February 2007 (PST)
Everything I had in mind, and more, was summed up in that speech. Well spoken. — Rapta (talk|contribs) 12:56, 8 February 2007 (PST)
I am almost afraid to point it out, but appart from him visioning a council to decide when a build is common and me a agreement (or call it consensus if you want), what Tanaric says is almost identical to my build proposal (especially the two bolded parts). --Xeeron 12:59, 8 February 2007 (PST)
You're correct. I wasn't trying to argue with you, only better explain why such a build policy makes sense, better define the word "common", and provide for some sort of implementation of consensus. I firmly believe that we cannot leave the editors as a whole to decide this. —Tanaric 13:02, 8 February 2007 (PST)
Question: PvE. You can get a way with quite a bit buildwise but it doesn't make it good. How do you address that? Since some PvE builds are quite useful, 55 builds come to mind but obviously a council of PvPers creating PvE builds is illogical. Split the namespace? Also, Lojiin 13:04, 8 February 2007 (PST)
That's too specific, this is simply regarding whether a builds section would be hosted, rather than specific question regarding a brand of builds in the game. It's illogical to have one at this time, or maybe even at all. The builds section over on the Wiki is a perfect example of how badly such a section can go. — Rapta (talk|contribs) 13:06, 8 February 2007 (PST)
Towards Tanaric: I can change the word agreement to consensus, but I was actually trying to go for the hardest possible wording that is not unanimous. That could mean in practise if more than 2 people DISagree that the build is common, it is not moved.
Lojiin, if a build is bad, it is unlikely to become commonly used (and to carify that up front, if everyone and their cat starts running echo mending monks in PvE, yes then we should document that as well, despite the stupidity). I am trying to move the process away from trying to document "what is good" towards "what is used", because the latter is much easier to establish. --Xeeron 13:12, 8 February 2007 (PST)
Oops, I didn't mean to get into the specifics so much. However it is somewhat relevant since we all agree that there would need to be a solid policy in place to control what was in the hypothetical section. Since, if no such policy is in place we either A) Don't have the build section, or B) end up with the mess similar to what currently is on Guildwiki. Lojiin 13:13, 8 February 2007 (PST)
And I am trying my hardest to prevent A and B at the same time. =) --Xeeron 13:20, 8 February 2007 (PST)
Can't it be a combination of both? A Whammo would be a clear example of "what is used", but it doesn't mean that it works well. Not getting too deep in the builds discussion (starting contributing here to get off builds), but there would obviously be a balance of both. — Rapta (talk|contribs) 13:15, 8 February 2007 (PST)
Look at this, 3 days into the wiki and we're already having a large-scale discussion on builds. O_o — Rapta (talk|contribs) 13:16, 8 February 2007 (PST)
Guildwiki convinced me that the definite focus should be on documenting rather than rating. Yes Wammos are horrible, but if they are part of the game because they are so common, they should be in here complete with a description what a wammo is. In practise I dont think it would ever be an issue, because there are so many different bad wammos out there that I can savely forsee myself agruing against each single one of them being "common" if the article includes more than a general description. --Xeeron 13:20, 8 February 2007 (PST)
But that does not really call for an entire builds section. A simple page titled "Whammo" as to "being a Warrior Monk which does very little damage" would mostly be enough. — Rapta (talk|contribs) 13:32, 8 February 2007 (PST)
Before I jump the "only use what we can see" bandwaggon, I'd like to point out a specific build, namely the vigorous paladin. I admit, when I posted it, the idea wasn't new, but in my whole year of playing GW, I only encountered that kind of warrior once. I'm fine with the proposals above, but do we want an exceptions? If yes, how would we proceed there? ~ D.L. (msg) 14:33, 8 February 2007 (PST)
If you encountered it only once in a year of playing, it doesnt sound common to me. Of course you can still put it on your user space, that is always a possibility (unless we adopt a restrictive user space policy). --Xeeron 16:05, 8 February 2007 (PST)
I am for documenting builds even if they arn't good. Sound crazy? It is just a fact of the game that for some reason new players flock to certain builds even though they arn't good. These are a part of the game. Maybe make a special subsection of the build section dedicated to it. If certain fairly specific build meets the common usage requirement, even though it isn't good, it should be included there.--Windjammer 09:10, 11 February 2007 (PST)
While I agree some process of review is required, I remind everyone that this is a wiki (isn't it?). Do we need to look at the definition of a wiki? Shouldn't it be a wiki if you call it a wiki? If you want a non-democratic (oligarch perhaps?) option, call it the official guildwars database. This is, perhaps, a technicality, but... Some builds are slammed by the community but are fun to play, some are "too close to XXX," and some are good. Generally all are different and are useful data--whether good starting points or what to avoid. Why not just be willing to host a builds database? Those that don't like it don't have to visit the buildspace, and those that do will be satisfied (and, hopefully, self-managing). I don't use any more because they have deleted the build database. Yes, I, like most, want it all in one place. Useful and relative mean something--people don't by Word to have to by a spellchecker... Perhaps this wiki, or 'wiki'-that isn't," will not get much use either... I hope builds are included and that it remains a 'wiki' (and useful).--Manos Lijeros
Yes, a wiki is a wiki. But a wiki doesn't mean you can add anything you want. A wiki is governed by policies and this here is the making of a policy. Also, your points are moot and the discussion has progressed further from this 3-month old section. You might want to read the rest of the discussions below or start a new section. -- sig 00:10, 22 May 2007 (EDT)
For the record, wikis aren't democratic. They're consensus-based. You can't get much further from democracy than that. —Tanaric 23:00, 23 May 2007 (UTC)
Autocraty is much further removed, but that is my opinion. --Xeeron 08:36, 24 May 2007 (UTC)

Classes of Builds rather than Specific Builds

What if, rather than articles on individual builds, an article would describe a known family of builds?

For example, there are different ways of building a Touch Ranger. Rather than spell out "Touch Ranger 1" "Touch Ranger 2" etc and end up voting or otherwise vetting each build to figure out which is actually a viable touch ranger -- the article Touch Ranger would describe the common traits of what a touch ranger is, how to build one up both in PvP and PvE, and how to play one. A selection of builds (perhaps just as Template strings -- GW build templates) could serve as example touch rangers, with no build beyond the most obviously popular ones being accepted as edits to the article without a discussion.

The idea would be to educate a guy who says, "Hrm, what this Touch Ranger people talk about?" rather than provide a platform for creative build designing.

The family of monk farming builds would have an article. PvE Runners. Minion Masters. Flashbots and cousins. Common PvP Monks (ZB, Prot Boon, Blessed Light, etc) Common GvG Warrior Builds. Each of these would be an article, updated as trends change.

This format would also make more sense for team builds that don't operate as individuals, in which often the way the build is played is ritualized and rote. IWAY, R-spikes, Eurospike, etc.

For builds specific to, say, Anguish or old Tombs, would it be better to present commonly requested builds in these areas as a brief description of the team positions in the article about that particular area? --Drekmonger 13:03, 8 February 2007 (PST)

What you describe for the touch ranger sound like a guide to me and I think there is general agreement that we want lots of them. Placing entire builds in the article of one arena seems like a recipe for huge unwieldy article however. --Xeeron 13:14, 8 February 2007 (PST)
I'm imaging, at most, a handful of example builds, either as links to other sources (such as GWshack) or simple template strings. An article on touch rangers would probably just include 2 template strings -- one for the original touch ranger from chapter 1, and one for the doubled up vampire touch of chapter 2. Two lines.--Drekmonger 13:28, 8 February 2007 (PST)
I'm in favor of the "guides, not builds" approach: it's much more important to describe the concept of the build than to lay out some predefined skills. It's one of those "give a man a fish / teach a man to fish" kinds of things. Now, writing good guides is a lot harder than writing good builds (Guildwiki still has pretty terrible guides, mostly), but I think it's more helpful in the end. — 130.58 (talk) 22:36, 8 February 2007 (PST)
It sounds like an interesting idea, and I have something a bit similar for PvE. Although it's true that a vast variety of builds work in PvE, you'll get people who go "How come I always die?!" (particularly some newer W's in harder areas). How about a page for each general build? For Elementalists, it'd be General ___ (Fire, Air, Earth, Water) Build and so on. Some skill combos synergize much better than others (maybe included in the skill pages instead?), and it'd serve as a general guide, particularly when newer Elementalists equip all the shiny new skills later on in the game, then find that they have no energy. Each "build page" could contain tips on what goes well together or at least a general layout (at least one E management skill, rez skill, etc.). Or, I guess that it could just be included on the profession pages. ~ File:GeckoSprite.gif Pae 08:44, 9 February 2007 (PST)

A Starting Point

It was mentioned at the top of the article but never really touched on. I think the first question that we need to answer is: Is there a community interest in having a build section on the wiki? Or put another way, 'Will Joe Gamer find a build section helpful'? In my opinion, yes, it is. Note that this is not a question of implementation, simply of usefulness, also that if the majority feels the answer is no, then the above discussion is moot as we probably should not have a build section. Lojiin 13:21, 8 February 2007 (PST)

I think the answer depends upon the implementation. If the implementation is controlled so that only builds that are actually used are documented, then yes, I think the community will be interested in our builds library. However, if it's a free-for-all like the GuildWiki builds section, then no, I don't think the community finds that helpful. Very few non-GuildWikians thought the GuildWiki builds were anything more than a joke, as far as I can tell. —Tanaric 13:23, 8 February 2007 (PST)
The large number of pageviews on guildwiki are a good sign that people indeed found the builds part (or sections of it) useful. The main issue is avoiding all the troubles that went along with it. --Xeeron 13:26, 8 February 2007 (PST)
Considering that a third of contributions on the GWiki went to the builds section, it would definately go in favor of having a section here as well. But obviously, the vetting system would be a complete overhaul. However, if we stick to documenting the builds we see on the website, very little can go wrong. — Rapta (talk|contribs) 13:30, 8 February 2007 (PST)

Resetting indentation to start a new question.

So since it seems we all agree the section would be useful, noting Tanarics implementation concerns. Can we next agree that PvE and PvP builds should be split? I would think so as they're entirely different settings. (Yes, small steps everyone, we can come to agreement :P) Lojiin 13:42, 8 February 2007 (PST)

Given the lack of a response (yes, it hasn't been that long but relative to the rate at which things are progressing today its been awhile), is it safe to assume this is the case? Lojiin 14:31, 8 February 2007 (PST)
I agree that it's potentially useful. I also agree that it's potentially harmful. The harm outweighs the usefulness, as evidenced by GWiki's build section. A wiki, where every contributor is equal, is simply not suitable hosting something where not everyone should be considered equal. Sure, we have a lot of views, but that's only because it's much easier to browse than forum browsing. Doesn't mean they're actually using. There are a huge number of other places where builds can be found (and we can link to them), but there's only so many times where arguments and frustrations take place before another emotional drama and tempers flare up again. It's the overall impact on the community I'm more concerned with than how useful it might be. This won't be like GuildWiki. It'll be worse, simply because the projected number of users will be much larger than GuildWiki. (talk) 15:53, 8 February 2007 (PST)
I don't think the harm will outweigh the usefulness if we can get a solid policy in place. That may mean that not all contributors are equal depending on the implementation. However, I think in principle the build section can be useful. As Tanaric stated, if implemented correctly, it can be a useful section for the community. Lojiin 15:57, 8 February 2007 (PST)
I actually think a larger number of users will be better for the build section. It will lead to less biases and a wider base of input. There were a small number of highly active user/editors and not enough typical user/editors to overcome the biases introduced by having a small number of high activity users.--Windjammer 09:23, 11 February 2007 (PST)

My opinion...

*groan* *moans* *shakes head* *walks away* --Karlos 14:05, 8 February 2007 (PST)

(joins Karlos) (talk) 15:53, 8 February 2007 (PST)
Agreed - can we all just leave builds while the rest of the wiki gets sorted out? Builds are on Guild Wiki so we're not taking anything away. Builds also equal drama, and the less of that we have at the beginning the better. --NieA7 16:22, 8 February 2007 (PST)
/agree, for the fourth time — Rapta (talk|contribs) 19:29, 8 February 2007 (PST)

More disadvantages

I'll add to the disadvantages of a builds section as it seems the experiences have not been mentioned. Builds is the best breeding ground for misconduct, plain and simple.

  • Sockpuppets or guildies praising another guildie's private build to make it common. So far there is no restrictions on this proposal to allow this not to happen and I don't see how there can be. Again, it will be a problem. How big a problem cannot be determined as yet, except for looking at past builds sections.
  • Even with the separation of private and common builds, there still exists egos, contributors that can't wait to bash a build (even a private build), and of course the highly educational reading of insults, mocking, etc. Yes, it can happen in any place for discussion, like this thread. However, from past experiences there has been but a faction of this type of behavior anywhere else compared to it on build talk pages and even at times moving to a user's talk page. Even longstanding users have contributed to these acts and I highly doubt their ways have changed much from moving from one site to another. In fact, if it was not for the builds section, the policy of no personal attacks would not have even been enacted on GWiki. Coincidently, there was not even a discussion regarding porting that policy until the builds section.

Don't let the excitement of builds on a wiki (again) pull the wool over your eyes to the increased misconduct and violations of policy that comes with it. — Gares 16:52, 8 February 2007 (PST)

I want to specifically point out that your first point is wrong with regard to the policy I proposed. Since it is NOT about simple majority, but about an agreement/consensus, no amount of sockpuppets can make a build common, as long as a substancial minority opposses the move.
Substantial minority ? Got to be best oxymoron ever :) 20:13, 30 March 2007 (EDT) Fun
Your second paragraph has very good points. However lets be clear about this: Unless we enact a policy that outright forbids all kind of builds everywhere in the wiki, builds will appear. And once they start to appear, some kind of policy regulating them should better be in place, because if it is not, the trouble with builds will increase ten fold. --Xeeron 03:26, 9 February 2007 (PST)


I would request everyone's indulgence for a little while longer. As noted above the consensus seems to be that there is a community interest for having a builds section. Noting Tanaric's observation that it only would be useful if implemented correctly. With respect to NieA7, I feel that its important to have a policy in place sooner as opposed to later. That is, before masses of people arrive and simply decide to create builds. With respect to Gares, these are things that need to be addressed in the policy. I think it most efficient to start at the basics and then work down into the little details. As many of us have come over from guildwiki we're aware of many of the potential problems and have ideas on how to address them. Starting from the premise, though, that there is a community interest in having a build section, should be split into PvP and PvE categories? And further, should those sections be broken into sub-categories? Lojiin 17:21, 8 February 2007 (PST)

Ok, I'm willing to look at this objectively and see if something can be made to prevent what the mess that once happened. But I don't agree with starting with categories. Categories are for organizational purposes only and is currently, IMHO, trivial. I see the need to define how we communicate to users that a build page is a community-accepted COMMON build, not a testing build, fix-me build, or other such crap we used to see. For starters, how about:
  • How do you plan on handling builds that were arbitrarily added? Is it acceptable to immediately delete them?
  • Do we accept common builds contributed by anonymous users?
  • Do anonymous users count when deciding on whether a build is accepted to be a common build? Especially if they only object to the build once and then disappears?
  • How many agreements is necessary before a private build is moved as a common build? Can we treat all users as equal?
  • How do we respond to less-than-knowledgeable changes to common builds?
The policy as is is too brief and many more clarifications are necessary. Given that this is a wiki, and the mere fact that some of the above work better if certain users are valued more than others is already in clear violation of the spirit of a wiki. (talk) 18:46, 8 February 2007 (PST)
Aberrant, you might want to add in your questioning not just anons, but one-hit registered users.
As to the builds section, Aberrant is correct. Work on the policy first and not get ahead of yourself thinking about categorizing and so-forth until a satisfactory policy is in place. — Gares 19:06, 8 February 2007 (PST)
The reason I mentioned the categorization first is because I believe different rules will apply. For example its easy to list only the guilds currently used in HA or GvG. However, those do not necessarily apply to PvE. So while yes, the categorization can potentially come later, since it has an effect on the policy I think it needs to be mentioned now also. Edit: the other reason I mention it is to get consensus started. It gets people agreeing with each other instead of arguing. Lojiin 19:12, 8 February 2007 (PST)
Also, re: Aberrant's comments. In my opinion, and feel free to differ with me, you're trying to take on the whole policy at once. I believe that it will be easier for everyone to agree to a policy if its taken one step at a time. Lojiin 19:26, 8 February 2007 (PST)
No, I'm not. I meant for those questions to be taken and discussed one at a time. To me, defining exactly how you plan on handling builds > defining how user contributions are treated > defining what is allowed content > defining how to organise the builds. Getting people to agree first is fine, but you have to start in the middle if not the top, but definitely not the bottom. Organization can come later. We can always decide later that if we want to split PvE and PvP, it is easy to split existing pages to conform to any category structure that's desired. But if you don't decide on the process of handling build pages first, then you risk prominent contributors getting confused and causing an unintended convention.
Along the lines of what you're trying to achieve, a better way to start is to answer this question: When exactly is an agreement reached about a private build becoming a common build?
If you're looking at a voting system, failure is highly likely, especially since the policy as is requires a unanimous agreement. (talk) 20:03, 8 February 2007 (PST)
Ok, that's fair. Can I get you to answer the question you posed? Also it seems we're accepting the following two basic premises : 1. That the only builds that should be allowed are the common ones. And 2. that any other builds should be restricted to the user namespace. As to your question on when a build is considered common, I think that for the most part when people are calling for groups by build name its a fairly good indication that the build has become common. This will not cover all cases I'm sure but I think it'd be a starting point. Lojiin 22:16, 8 February 2007 (PST)
I suggest that a build could be considered common/useful if there's a large enough body of knowledge about it to write a really good general guide for it. No builds without an associated guide would prune quite a bit of the garbage. Then the quality/accuracy of the guide could be assessed rather than the build itself.--Drekmonger 22:48, 8 February 2007 (PST)
Then why not just go for really good general guides with a few example builds? Which is to say that we need neither a build section nor a build policy, just very good "Mesmer/Elementalist", "Warrior/Monk" guides... --NieA7 03:23, 9 February 2007 (PST)
The more good guides, the better. But we still need a builds policy, because builds will appear without one, check my reply to Gares one section above. --Xeeron 03:27, 9 February 2007 (PST)
Depends what we mean by builds though. Build:Me/E Flashfire is a specific build but also an example of a fast casting elementalist. There's no reason it couldn't be pared down to Auspicious Incantation, Fire Attunement and Echo with the rest as optional slots and included as a simple example in a FC Ele guide (similar to the build stubs in the General minion mastery guide). Something like that clarifies what's needed for the basics of the build without going into huge depth (the guide can then go on to list several examples of what could fill the optional slots). Maybe I'm too hopeful at this point but I wouldn't have thought that would need seperate policies. Core of a wammo is mending, sever artery, gash and final thrust, nobody's going to get worked up about that are they? --NieA7 03:37, 9 February 2007 (PST)
But what do you do if someone comes along and fills in the optional slots, arguing that these are the best? And person B comes along and feels different, so person B puts up a different fast casting elementalist? That will happen, therefore we need a policy for builds. --Xeeron 05:19, 9 February 2007 (PST)
Whatever the policy is, it should produce stuff like this: ... not stuff like this: When we go into build category, I want to see a few detailed articles like the linked 55 monk guide, not an unmanageable, unreadable spammage of every build everybody could possibly think of. Suggest that builds not appearing in the context of guides are left in user space and deleted elsewhere.
Why not only include builds as subpages of guides, then? Like "Invincible Monk/SS variant" (pretend that slash is actually functional rather than a kludge) instead of "Mo/N Invicible SS monk"? — 130.58 (talk) 07:53, 9 February 2007 (PST)
One thing it seems to be that diffentiates the questions of Builds on this site as opposed to GuildWiki is the idea that potentially this wiki will be called up directly in a game client. (At least that was my understanding from Mike's comments.) Therefore, there is a possibility of being able to support direct loads of templates from the wiki straight into a game client. This has enormous potential for good. Although I can see that it would be fair to restrict (say) Joe Bob's Awesome Paragon/Assassin build, a reasonable collection of good quality builds would be enormously beneficial IMO. Would it be possible to (say) organise a specific group of people that have the ability to vet, edit and post builds rather than open to the general populous?--Vladtheemailer 12:10, 9 February 2007 (PST)
I doubt that such a thing would work because there'd be complaints about who was able to vet and who wasn't and it would essentially degenerate into the same mess that is the Guildwiki build section now. Though I can see where, if/when the wiki is linked to the game client that it would be useful to load builds. Lojiin 12:15, 9 February 2007 (PST)
With an in-game client import feature possible it seems like it would be a damn shame to have no builds at all here... and it'd probably be almost as bad if it only had examples of cliched builds (Wammos/55 monks etc..)--Vladtheemailer 12:21, 9 February 2007 (PST)
Mike envisioned it as an in-game help system, where people can check for help if they're on missions or quests, something like an in-game browser or something. Definitely no suggestions of any import system. (talk) 09:34, 10 February 2007 (PST)
An import is just blatant speculation, and no policies or guidelines here should be built around something that does not exist, and which has not been stated to be planned. The builds section in GuildWiki is margionally useful at best, but more often then not viewed as an untamable wasteland by many. Wikis are not and never will be well suited for any type of testing/vetting process. --Barek 09:44, 10 February 2007 (PST)

Guides, not builds!

Builds on Guildwiki were terrible. They also weren't very helpful. You could point to a build article and tell a person what to do, but they'd still be a clueless newb as to how to do it. I've seen a fair number of people running wammo farming builds straight from Guildwiki in general PvE, for example. As long as we have a fair number of people who are actually interested in writing guides, I anticipate fewer problems with guides than with builds -- just the fact that the guide actually explains its suggestions goes a long way towards that. — 130.58 (talk) 07:51, 9 February 2007 (PST)

I think "Guides not Builds" is the best policy, or simply including builds as subpages of guides for the purposes of illustration. That said, I think that some documentation of common builds is useful. When someone says "zergway", I want to come here and see what they are talking about. I hope that any policy that we all agree on can include at least a robust glossary idea (I don't need skillbars, but I want classes, key skills, and a description of what is going on). Oblio 08:22, 9 February 2007 (PST)
Exactly. — 130.58 (talk) 08:25, 9 February 2007 (PST)
You should start writing down your ideas as a policy proposal (including the way it is going to be enforced). I guess we all already agreed that guides are great at least 10 times, what we need is something that can become policy. --Xeeron 08:42, 9 February 2007 (PST)
I'd be ok with just limiting it to guides. I think that most of the useful builds could use, or have, existing guides. I think it then becomes important, then, to define what makes a guide useful enough it qualifies to be posted. Since any old Joe Schmoe can write up a "guide" but that obviously doesn't make it one. Lojiin 09:02, 9 February 2007 (PST)
Xeeron, that is surprising difficult. I tried to take a stab at it at User:Oblio/Sandbox#Build Policy (just ignore the stuff above it), but we get into all kinds of issues about "what criteria is acceptable for inclusion of a guide in the wiki". Some of this stuff might be easy, such as a class guide, but what about "underworld duo-farming guide", what about the "echo-mending monking" guide? With normal objects in the wiki, you have the criteria of "it exists", so there is no controversy about the entry for Steel Daggers, but things get confused for Solo Elementalist (though that may even be OK). I _THINK_ the solution is to use the same criteria for inclusion of a guide that you use for every other page in the wiki (quality, NPOV, usefulness) but honestly, I don't even know what the process is for arguing that Steel Daggers should/should not exist. Oblio 09:31, 9 February 2007 (PST)
Thanks for trying none-the-less. I am not at all surprised it is difficult, but that is the difference between vaguely talking about what one wants and writing down exactly what one wants (and what one not wants). We need the later to find a policy. --Xeeron 09:42, 9 February 2007 (PST)

I'm all for completely banning them, but if anything is gonna happen.. please instate a tight policy that demands usefulness and prevents the creation of a new page without some discussion. For GuildWiki, anyone could just log on, chuck out a skillbar and 2 lines of text and there was nothing to stop them, and then you had to get 3+ people to push it under the doormat which is rediculous. Whatever happens I do not want another BuildWikiSkuld 09:38, 9 February 2007 (PST)

What is "them"? All buildes and guides? If not, what is the difference between buildes and guides? Is an example build in a guide a build or a guide? Is someone putting up a skill bar with attributes on his user page a build or a user page? What happens with stuff deemed bad? And worst of all: Who decides whether it is one or the other? --Xeeron 09:42, 9 February 2007 (PST)

I wanted to mention that GWIki guides have been most successful when they take the form GWIKI:General Trapping Guide, but some builds are written so much like guides that I think they should also be viable candidates, such as GWIKI: UW Trapping team. One of them uses example builds, one of them lists builds, but lists variants. The key to both of them is they explain an environment and a strategy, and then they fill in useful and precise information about specific considerations of those environments and strategies. The thing is, I bet at least one of you thinks that one of those 2 articles should not be considered a guide. That is what needs to be iron'ed out. Oblio 11:05, 9 February 2007 (PST)

Working off of Oblio's example, my sad semi-pathetic attempt at a policy. User:Drekmonger/Sandbox --Drekmonger 11:47, 9 February 2007 (PST)

Builds should only really be kept to a user's namespace. — Rapta (talk|contribs) 11:51, 9 February 2007 (PST)
Including well-known builds like "Thumper", "Touch Ranger", or "Invincible Monk"?--Drekmonger 11:58, 9 February 2007 (PST)
Guide material, really. — Rapta (talk|contribs) 11:59, 9 February 2007 (PST)
My current thinking is that builds should only be on user pages OR sub-pages of other pages (used to illustrate examples). So sub-pages of guides, sub-pages of glossary entries, etc. (to clarify -- I think a builds section is a mistake, and would generally be against it. This does not preclude builds from existing for documentation purposes as linked subpages of information articles. ) -- Oblio 12:02, 9 February 2007 (PST)
I would be ok with them a subpages to guides. Where they're a specific implementation of a build being illustrated in the guide. And like Rapta said. Most to all of the good, useful builds can be written up as guides. Lojiin 12:03, 9 February 2007 (PST)
As Drek has been saying all along. I suppose I'm trying to be clever, calling guides "Build Guides" so they can be slotted into a "Build" section ... Oblio's links above are superior examples of what I would call a "Build Guild". The idea being to demonstrate the build section as something useful via populating it with guides, so that no one else comes along and starts up their own less useful build section.--Drekmonger 12:08, 9 February 2007 (PST)
And sort of half-agreeing with Skuld here, builds should be kept off the Wiki completely, limited to userspace pages. Then, when the bulk of the material (ie policies, skill pages, monster pages, attribute pages) are ready, then maybe a builds section could be created. But right now, I don't see this happening to much effect. — Rapta (talk|contribs) 12:05, 9 February 2007 (PST)
While I agree builds are of lesser import than the other material I think it would be better to have a policy in place now before someone comes along and creates the section pointing to the fact that there's no policy. Even if the section is left empty initially with a policy in place from the beginning I feel it would be much easier. Lojiin 12:12, 9 February 2007 (PST)
For PvP builds, 8v8 concept guides are more useful than the individual 64 skill layout (let alone individual characters). What I envision as useful build links would be to common builds like eurospike, kgyu pressure, things like that. For example, a kgyu build could be described as having a mix of warrior pressure with condition rangers, and then list out a sample build composition, like W W W R R Mo Mo N/Mo. I also believe it would be helpful to list historical builds so new people could understand what is being referenced. Builds that spring to mind are gale jail+crip shot, sb/ri, 4xthumpers, and fast cast air spike. While many of these builds can no longer be run effectively, there is a definite historical use in letting people understand how the game has shifted, why it has shifted, and what old builds share in common with the new ones. --Trevor Reznik 17:17, 9 February 2007 (PST)

I'd like to simply note that "Guides, not builds" seems both far more useful to our users in general and far more wiki in nature than specific build data is. —Tanaric 17:27, 9 February 2007 (PST)

The changes made by Xeeron seem like a positive step to me, although I would like my opposition to the use of subpages on the main namespace to be noted. I think it would be a lot better if the "build" was not a subpage but was just part of the article. LordBiro 04:18, 10 February 2007 (PST)
This could lead to overly long articles (think of making an DoA mission guide, any build example would boost the guide to huge lengths). --Xeeron 05:14, 10 February 2007 (PST)
Couldn't the description of a build for the DoA (be presented as a guide, perhaps a subpage to the DoA. It would be a guide a to running ... whatever build ... in the DoA, with the build itself presented as an example. If there are multiple, popular teams specific to the DoA, then multiple guides. "Guides" that only exist to present someone's pet build as an example could be flagged for improvement or deletion.
PvP builds handled in the same way. "Blood Spike", for example, could be a subpage of HA or a general PvP build article/category, but presented as a guide to building and running a blood spike team. If someone were to just spam out a blood spike bar without the associated tutorial, it gets flagged. Or if someone were to spam out a blood spike bar when there's already a Blood Spike tutorial, the bar could be added to the tutorial if it's extremely relevant, or deleted as redundant if it's not.--Drekmonger 09:06, 10 February 2007 (PST)
I dont get you. A "guide to running a build" has always been ... a build article, since most of those include a detailed usage part. It sounds to me as if you are simply renaming detailed builds to guides for the sake of this policy. --Xeeron 09:16, 10 February 2007 (PST)
Difference between a guide with builds and a build with a usage section is the focus. The builds on guild-wiki tend to be a build, followed by a short bullet point usage section, followed by a short bullet point variant section. A "build guide" would a tutorial with real live paragraphs on playing a certain role/running a certain type of team (including all the trivia of splits, positioning, what you should be saying on vent, what do do in different situations etc.) followed with some examples for builds/variants.
I don't know how to express that as concrete policy.--Drekmonger 13:07, 10 February 2007 (PST)

I agree with the Guides not Builds policy. Just say what the purpose of the build is, and what skills are needed for the build as well as listing some possible alternatives. --Vindexus 13:01, 10 February 2007 (PST)

I think it will probably be best off just not touch builds and guides at all. There is way too much influence from Guildwiki. For example: Guild Wars Wiki:You are valuable. I think too many of the people from GuildWiki want to try and just take all the policies and plug them into this wiki for it to have a prayer with builds or guides. Builds and Guides need competent, experiences players and a willingness to recognize that some people have no clue what they are talking about while others do. Whenever someone posts a build they tend to be super defensive over it "I know my build is great, you are all wrong and don't even test it!" and all they need to do is convince a few of their friends to come and post "This build is great" before it gets in. The frustrations with having their hands tied and not being able to correct incorrect information ends up driving the PvPers away and leaving anyone trying to fix the process vastly outnumbers. I don't have faith that the leadership exists to pull off a proper build section on this wiki, even if you only allow "guides" posted. I think it would be best off to admit the wiki's shortcomings, have an official policy of no builds and guides, and then direct those who really want to post builds on a wiki to Guildwiki. -Warskull 16:39, 12 February 2007 (PST)

I was actually thinking of something a bit more extreme than what some of y'all here have said. When I say "guide," I don't mean "detailed usage instructions for a build." I mean "a thing that guides you through the kinds of decisions you'd have to make when designing your own build." Let's say you have a typical Shock+axe build, for example. Yes, you could write a long article about just how to cancel Frenzy and when to use Shock to back up a spike and all that, but that's not what I'm going for here. I'm going for an article that actually says "Here is the huge list of decisions you have to make to create that Shock+axe warrior build." Something that will actually make the reader a little bit better as a player when he's done reading it. — 130.58 (talk) 16:43, 10 February 2007 (PST)

Am i the only one who LIKED the builds how they were? i mean, sure most of them weren't specific enough, but, once you had the information, stats, skills and basic usage, the rest was up to you. Sure, you would most likely suck the first time you used a new build, but once YOU developed a style and method for that build, you were all good. What i suggest as the new 'builds page' is guides, on common builds, for example; Minion Master, it would explain what it was, how to use one, and the SKILLBARS and equipment of alot of different variants, and also information on how to create YOUR OWN variation of that build, what is the core and main strong points of the build, and what not to do with it. I suppose another good example of this would be: Spirit Spammer, almost all ritualist builds on the build namespace are based on some sort of variant of the spirit spammer, that is basically what the ritualist profession is, using the above example, you could create a guide on The Spirit Spammer. I also think that having skillbar images, and links to each of the skills is imprtant to guides, it is a visual aid, stops people from becoming disinterested, and helps A LOT with new players wanting to use a build. 09:23, 17 April 2007 (EDT)

First, decide on "Roles"

I just want to voice my agreement with the general concept of "Guides not Builds". I often argued in favor of the Guildwiki builds section, and the reason is that it was the most important section for helping me learn how to put a build together, and learn how to play the game in general. Its also so much easier to point friends and guildmates towards community opinions on what a good build is, rather than trying to convince them to listen to you and having to worry about sounding like a know-it-all, or them getting offended by being told how to play. I think guides are a great idea, but I definitely think that there must be at least one example skillbar and accompanying attribute point/rune setup, to help the new players "get it". Everyone is worried about people fighting to agree on the skillbar, but the main reason these arguments get so messy is because of build ownership. If the build was posted as part of a guide article, this would be much less likely to happen. If there were any disputes about the chosen skills, then use optional slots and list variant skills for the contested slots. I think the problems with the guildwiki builds section was not the users, but rather the environment they were given. Just because things got so messy there, doesn't mean that we can't come to agreement on an example skillbar for a build guide. Let's give ourselves some credit.
So if the answer is "Guides Not Builds", the first question is, how do we decide what guides get created, and how do we prevent people from simply creating a guide for the purpose of getting a build published? I think the answer is to decide on "Roles" first. A lot of new players have trouble understanding what the role of their profession should be, especially more subtle support roles for mesmers, rangers, or paragons. Each Profession page should have a section for common "Roles". This could include "interupter", "beastmaster", or "elementalist farmer". Then create the guides for each of those roles, and then add the example skillbars last. What roles should be included for each profession is something that should be reached via consensus on the profession page for each class. What Vallen did on guildwiki with the effective ranger guide and the interrupt guide etc is a perfect example of this general idea. I think, if Vallen licences the content, we should use that as a template for other profession guides, and the appropriate builds. Integrating the guides and example builds so closely into the main article structure will mean that the average user will not feel comfortable jumping in and adding builds, and the free-for-all that happens on guildwiki will not occur, as the environment and encouragement will not be available. -- BrianG 21:39, 9 February 2007 (PST)

This idea is good, although it must be presented in a way that as not to imply that the roles are final and that no new roles could be added. Another thing is, you might be underestimating what certain users might do. Having a skill bar there with optional slots, you'll see a slew of strange suggested variants. But yes, making it read like a guide will certainly help keep these users away. (talk) 09:39, 10 February 2007 (PST)
Yes, the roles would be decided by consensus on the talk page of the profession article. And if someone wanted to propose a new role, they would have to be willing to write the guide for that role. Writing a guide article is a lot more difficult than pasting a build template like on guildwiki, so I really think this will control things much more than we realize. The major reason the builds section got so out of control was because it was SO easy. Anyone could add a build, even if they had no idea about wiki code, and had never even edited an article. The type of people who collaborate on articles are the same type of people who will be able to be reasonable when discussing suggested skills for an article etc. If people come along and start throwing variants into the article with no discussion, we can just revert the page the same way we handle other articles. -- BrianG 10:30, 10 February 2007 (PST)
Yes to everything BrianG wrote above. Re: roles, Obviously, roles wouldn't cover articles on certain types of teams, but it would be a decent policy for describing single characters. We don't need a full article for both ZB monks and prot boons, for example. They both play the same role in a GvG team. --Drekmonger 13:21, 10 February 2007 (PST)
I'm completely in favor of the "Guides not Builds" idea here, and I'm also liking what I'm seeing here. Sounds like a good way to keep things less cluttered and more useful. As for roles, I can still imagine someone blurting out "DO MASSIVE DAMAGE!!1!!1one" and throwing out 8 skills and calling it good. I don't think we could ever totally get away from that, but with a requirement on purpose and having a more complete guide it would be a lot easier to weed out the garbage.--VGJustice 23:45, 10 February 2007 (PST)

Sorry to use drastic words, but that proposal is totally horrible. Reading sentences like "The major reason the builds section got so out of control was because it was SO easy. Anyone could add a build, even if they had no idea about wiki code, and had never even edited an article." and ideas about setting up complicated structures with the only aim to turn editors away makes my wiki-sense puke. What you propose is the total opposite of what a wiki should be. How can it ever be bad if someone new finds it easy to start editing? --Xeeron 04:02, 11 February 2007 (PST)

Partially agree with Xeeron, but still requiring more work from a build document will help with quality, I believe. Ultimately, the intent of getting everyone to help edit is to improve the quality of the wiki, not nessessarly quantity.
For example, allowing people to write up their personal characters/fanfic/gameplay suggesstions in their own native language as main space articles would make it easier for new people to start editing. But the outcome may not be desirable for the maintainable quality of the wiki.

--Drekmonger 07:33, 11 February 2007 (PST)

Xeeron, sorry but I think you are being reactionary and taking what I said out of context. Did you read the whole thing? I never, anywhere, suggested we should setup "complicated structures with the only aim to turn editors away". And I certainly didn't propose anything that would make editing more difficult. I suggested a rational system that would make example builds part of the article structure, which as a side-effect, would happen to discourage people from posting 'personal' builds, which create ownership issues, controversy, and a flood of builds as seen on guildwiki. But the main purpose of my proposal is to have example builds included in guide articles, not to make anything more difficult. I was only trying to reassure people that just because we will include builds in the articles here does not mean people will be unable to control themselves. I didn't mean to imply that making editing easy for new users was a bad thing, and perhaps I chose the wrong word when I said "SO easy", I was just saying that if we don't want personal builds on the wiki, then just don't give people an open forum for personal builds, and people should be able to control themselves when it comes to articles. Please, explain to me how requiring consensus on an article talk page about what roles a profession should perform, and then creating a guide article for that role, is the total opposite of what a wiki should be. There is a big difference between "making editing difficult for new users to start editing", and "requiring users to reach consensus through the talk page about what roles and guides are needed for each profession before allowing them to create a build article". -- BrianG 07:49, 11 February 2007 (PST)
I must say I actually liked the structure of the builds pages that showed the skills, the equipment and dot points explaining all of it. It was easy to read. But I didn't like that anyone could submit any sort of build and anyone could vote. That is what was meant by the "easy", yes? I liked the comment before about documenting what is used, not what is new. - BeXoR 07:52, 11 February 2007 (PST)
Yes, thats what I meant, and yes, I loved the layout of the build articles as well. It just seems like everyone here does not want to have personal builds on this wiki, so I was just making a suggestion that would allow for builds to be included as examples in guide articles (because I think thats important to help beginners understand builds), without creating the problems involved with an open forum for personal build submission. -- BrianG 08:11, 11 February 2007 (PST)

Some Things to Think About

I have tried to read as much of this discussion as possible but it is like a book so I picked up on some general ideas from it. I honestly didn't have a problem with the builds section on the old wiki. Sure there are some crappy builds, but label them as unfavored when people call them out... big deal. Here are the points you have to think about with not having a build section here or even limiting it severely.

  • We always complain about people using packaged builds that everyone else uses. Having only the "popular builds" simply encourages this. Visitors see these popular builds and use them as well.
  • The Wiki is meant to be a place for facts, but as discussed with the user pages, this place is also meant to be a community. Players like sharing and reading build ideas. Some of us might not, but why deprive some users of this aspect?
  • It was mentioned to have a PvP counsel approve builds, this isn't a bad idea... but please remember that often builds are disapproved on the basis that "it sucks for PvP"... when duh, it was meant for PvE. You need to have people who know PvE as well.
  • Even if some of the builds are crap, they really aren't too hard to be labeled as such.
  • Builds placed only in user pages will basically never be viewed by random visitors. Only if you know they are there will you find them. I guess a category could be used, but this isn't any different from just having them as regular pages.
  • The nice thing about the builds, even the bad ones, is that it gives other players ideas. This is the diversity that you want in what you see in game. Hell, I personally look through all the builds to just get an idea of some combos that people have used, then refine half the skills, points, etc to make a damn nice build I would rather keep secret.
  • New players can see that they can come up with a variety of builds and they aren't stuck to just those few popular builds. Just because most of us posting here are experienced players and know how skills interact, doesn't mean the visitors do. Allow them to see different combinations can be made.

To sum it up, basically I feel that if you remove the builds, you are taking a big chunk out of what makes the Wiki a community. If you restrict it severely, you are limiting creativity and variety in the game itself. Allow builds as they were with maybe a new vetting procedure. If you don't like watching them or editing them... then don't. --RabiesTurtle 08:33, 11 February 2007 (PST)

GuildWiki isn't going to cease to exist, as far as I know, and with the number of people that dislike the builds section (myself included) why bring it over here? The arguments and everything else that was caused by it IMO are not worth it. It's established enough at guildwiki and I see little reason for it here. --FireFox Firefoxav.gif 08:41, 11 February 2007 (PST)
Its all nice talking about it, but look what happened at GuildWiki. Tanaric's point again: "the wiki is not a research and development lab". Check out Drek's Thumper page, this is the right idea. — Skuld 08:46, 11 February 2007 (PST)
What happened at GuildWiki Skuld? It was a userful reservoir of build ideas (including PvE builds) until some people got it into their heads they'd rather deprive the rest of us of a valuable resource than have a section that didn't conform to their sense of aesthetics/policy. --Ctran 05:47, 13 April 2007 (EDT)
My plan was to hold off writing anything that resembled a build until the policy was in place. The Thumper page, while nice, is not mine. It is a good start on what I hope a "thumper" page would be, and an okay example of what build pages in general could be.--Drekmonger 09:41, 11 February 2007 (PST)
I guess leaving the builds out or restricting them severly is nothing bad. For explicit builds, there is always gwg and gwshack, we really don't have to burden ourselves here with hundreds of trash articles. ~ D.L. 08:56, 11 February 2007 (PST)
If you don't want the burden, fine... don't look at them. It is pretty simple. I really don't see what the problem was at the old wiki though. Why it is an issue if there are a lot of builds? Why not let people see and have variety? Have you ever tried looking around GWG or GW Shack for builds? It is a complete pain since you can't really narrow down or filter the results on Shack and Guru is difficult since it is forum based. I guess I really just don't see the problem with allowing builds here. If you don't like them, don't read them. If they feel like a burden, don't try to moderate them. There are enough visitors and other members to fix issues. --RabiesTurtle 09:39, 11 February 2007 (PST)
ooc, if guild wiki's build section meets your needs, why are worried about propagating the system over on this wiki? Does that basically making twice the work for those who have be concerned with moderating/publishing new builds?--Drekmonger 09:45, 11 February 2007 (PST)
I was responding to Firefox above and the edit conflict is allowing me to put this down here instead...
Hopefully, this new site will take off once the data gets added on here. I have a feeling that most people will move over and the old wiki will not be updated nearly as much as this one. Skill changes, new campaigns, etc will all make builds on that site much more difficult. They way I read the purpose of this site was to move the old wiki over as legally as possible with new official hosting. Personally, once this one gets the information from old wiki, I am abandoning that one since it won't even load for me at all right now. If you are talking about twice the work too... consider that you would have to updating the skills on both sites if you want those builds to work right, to me, that is twice the work when this new site could easily support both. Another quick note... everyone here who is talking about not needing a builds section readily admits they don't use/like the old builds section. There are a ton of visitors who do use it for some purpose though, you have to consider what might be helpful to them. It is the same reason we document even the smallest things like what Gold is.... some people might like the reference. --RabiesTurtle 09:49, 11 February 2007 (PST)
Hrm, I assumed the old wiki would continue on as a sister wiki for the foreseeable future. I dunno if that's true. Suggest a more palatable means of moderating new builds, and people might change their minds. For now, I continue to like the "Guides not Builds" and/or "Builds as Guides" approach.--Drekmonger 09:55, 11 February 2007 (PST)

GrammarNazi's two cents.

While I will agree with many of the administrators that have posted in this discussion so far that the old system was more flawed than polished, I think that completely excluding non-standard or experimental builds is alienating a whole audience. Builds don't have to be intrinsically good to be helpful to the community; bad or good, a build gets a concept or idea out there and is always able to find a home in somebody as a result.
A tried-and-true build will help a new player looking for something to use; this is an obvious point. However, the usefulness of a 100% tried-and-true build (or "guide") collection on a Wiki disintegrates when one comes from the perspective of a player looking to see if their own concept is viable or not. In addition to that point, there exists people who want to see what others are thinking as a means of inspiration for devising their own build. Removing all but the GvG-worthy guides would eradicate this use of Untested or Experimental builds.
Rather than trying to ban all Builds or ban all Guides, I believe a more welcoming choice for the community would be simply to section the two of the concepts off. That is to say.. Guides - Profession combination concepts that never seem to leave the game.; Build Discussion - Profession combination concepts that can be discussed, edited, and reviewed. The Build Discussion section would be an extremely volatile, but open forum. Rather than deleting builds because an administrator doesn't like them, these build pages would function more like an open forum that begs the question, "What do you think of this, guys?" and could be opened or closed on the Wiki users' discretion.
Lastly, I'd like to emphasize the following: given that every reader is different, and the value of material on a Wiki varies accordingly, I think that settling this debate with an ultimatum (builds or guides) is not a realistic option if we want to start the official Wiki off on a good foot. GrammarNazi 10:01, 11 February 2007 (PST)
Edit conflict (twice geez) but I suppose this reponse fits here too: I would encourage everyone to remember that the way gwiki does things isnt necessarily the best way, and we have the freedom to explore that and find new, better ways to operate, without the pressure of systems already in place. Personally, I used the builds section for farming builds, and occasionally pve team builds, but I saw the mess they were in and how poorly the system worked. When I wanted to learn about community builds and ideas, I did NOT go to gwiki builds, I went to a forum. I will always stand by a wiki being the place to document the game, not to develop ideas for the game. There are other places better suited to that. - BeXoR 10:03, 11 February 2007 (PST)
Certainly, the beauty of Wiki is that it can change. I definitely want to see Guides implemented, because I find that this concept is one that was sorely needed in GWiki. That being said though, the volatility of a Wiki and the volunteer-oriented, troll-free spirit that comes with a Wiki, in my opinion, makes it just as good of a place to discuss Build concepts as a standard forum; at the very least, it is more welcoming and can often be more active. Additionally, the ease of formatting Wiki pages to give examples, show images, etc. also makes the Wiki a place conducive to an open discussion about build usefulness. I personally feel that while the Wiki is a perfect place to document the game, it is also a very convenient place to discuss the game. GrammarNazi 10:07, 11 February 2007 (PST)
No one has suggested limiting builds to GvG worthy only. The best guides on guild wiki concern PvE builds. Futher, as this very page proves, wikis are not the best place for discussion. That's why internets gods invented forums, imho. I suggest the best place to get feedback for a new build is a forum, be it gwg, guild-hall, or gwo. The best place to publish a build meant for your own team's consumption is gwshack. Wikis excel at publishing common knowledge.
Which isn't to say that "new" builds should be excluded althogher. If someone can invent a new concept for builds (say a Hamstorm warrior team that really works) then after extensive testing it should be possible to write a really good guide for that working build. I can't see anyone wanting to delete a good guide, regardless of subject.--Drekmonger 10:09, 11 February 2007 (PST)
I did not intend for you to infer that builds would only be posted if they were GvG worthy, so I'm sorry for how I phrased my observation. I believe that "guides" as has been discussed on this page need to be in the Wiki, without a shadow of a doubt. I was drawn to the GWiki community because of how welcoming it is in comparison to the very forums you recommend.
Additionally, I'd like to make the distinction between Guide and Build. Earlier, someone linked to a "Thumper" Guide. This is what I mean by Guide - a concept as devoid of specific skills as possible in order to allow for reader interpretation and a personal spin; and what I mean by Build, is both a comprehensive and specific interpretation of a Guide that is open for discussion. The significant difference between my proposition and what is currently on GWiki is that there isn't a "higher level" to achieve with the Build. The Build page can be deleted or revised at the Wiki author's discretion. GrammarNazi 10:18, 11 February 2007 (PST)
Oh, and one more thing to add. The proposed Build Discussion section ought to be defined differently than "Build", and only the Build Discussion would make Main Page, to make it clear that the section is mostly for clarification and exploration. GrammarNazi 10:21, 11 February 2007 (PST)

The Policy I Think We Can All Agree On

  • Guides about a position/role/team are welcome and encouraged
  • Builds outside of a guide are strongly discouraged. Except on user pages.
  • Prior bullet is open for revision when/if guild-wiki dies. Because I don't think it will.
  • Separate sections for PvP/PvE Guides (about builds) and a free for all heap for Untested Builds is not ideal, but acceptable if the trash heap is buried several layers under the good stuff, where the PvP community can't point at it and write off this wiki as "weak sauce". But I still dislike the notion.

That will be my stance. Going to shut up on this subject now.--Drekmonger 10:30, 11 February 2007 (PST)

I think that is a sound stance, and if the guide categories are well parsed then no viable builds will fall outside of them. However, how will the guides by categorized? If by roles: do some viable builds defy rolecasting; what are all the roles? If by profession: would that be in danger of unfairly type-casting some professions?--Windjammer 10:49, 11 February 2007 (PST)
By arena of use. PvP-General, PvP-HA, PvP-HvH, PvP-GvG etc? PvE-General. PvE-Farming. PvE-Mission Specific? Anyway, that's how the PvP guides need to be organized. I have no idea what would be most useful for PvE players.
Shutting up for real now.--Drekmonger 10:55, 11 February 2007 (PST)
I completely agree with all of your points, though I personally feel that your fourth bullet is important to include(the recommendation you make should be emphasized, not the content). I don't think Untested builds should be readily accessed in a manner that would garner them heavy publicity; I also don't think they should be categorized as Untested builds, as I've posted above. I believe they ought to be changed into Build Discussions with the intent of getting other people's opinions as opposed to trying to upgrade them into full-fledged strategies. This is merely a digression though, I think all of your points are very important to consider but I simply feel that not including the weaksauce would be...well...weaksauce, haha. GrammarNazi 11:27, 11 February 2007 (PST)
In regards to Drek's PvE question - a reader who is stuck in a Mission, or perhaps wants to learn more about a Mission, will naturally gravitate towards the Mission's entry itself. That being said, I think the PvE-Mission Specific ought to simply categorize Missions by Campaign, and include recommended builds along with the strategies under a separate section for each Mission page. PvE farming ought to be organized similarly by location. Any Farming builds that apply to more than one specific location can have their own, "General Farming" entry. Lastly, PvE General is general so...I would imagine there's no need for further categorization. GrammarNazi 11:34, 11 February 2007 (PST)
I personally think that GrammerNazi's first idea under the previous section is a pretty dang good compromise. Some have mentioned that we want guides or maybe the basic popular concepts... so have them. We can separate user created builds from these guides.
Another quick thought. It keeps being mentioned that this wiki is about documenting things in the game only. Well, we add suggestions and guides to skills, missions, etc right? Just because it isn't a hard fact, doesn't mean it isn't useful to visitors. I have the same feelings about the builds section. A build might not be used by everyone, but a player can certainly document that he uses it or that he thinks it is useful. Here again though, go ahead and distinguish guides like Skuld mentioned earlier with the Thumper page from the builds proposed by players. Seems like the best of both worlds honestly. --RabiesTurtle 12:24, 11 February 2007 (PST)
Slightly less terrible? Constrain user builds to user space, but have a category that indexes user builds on user space. Discussion of a user build can occur in user space. Those who enjoy playing Build Wiki can do so in user, but without the structure present on guild wiki that creates the Build Wars popularity contest.
Naming convention would be User Name's Whatever. So if I made a user build I'd called it Drek's Hamstorm and place a link to category: User PvP builds. Question: can a category be sorted by date of last edit for an article? (Probably not.)--Drekmonger 13:14, 11 February 2007 (PST)
As a subpage it would be "User:Yourname/D/Mo Blah Blah". - BeXoR 20:29, 11 February 2007 (PST)
"PvP HA warrior guide" would have a lot of information that was redundant since it also appeared in "PvP GvG warrior guide" or "PvP TA warrior guide". Really I'm thinking maybe something like "PvP warrior guide" + "HA guide" + "sword warrior guide" working together to provide meaningful information might be most appropriate. — 130.58 (talk) 20:33, 11 February 2007 (PST)

Alright, having just read this entire talk page within the past 45 minutes (and having only discovered a couple hours ago that Guild Wars was now hosting a wiki) my brain is slightly fried, so if I lose coherency at some point, I apologize.

I am extremely in favor of the "Guides not Builds" idea. I mentioned on the other wiki a couple times that one of the issues I had with the Builds section was that it wasn't objective, something intrinsically necessary for a wiki. Someone, somewhere in that huge amount of discussion above this post, mentioned the "Give a man a fish/Teach a man to fish" idea. On this wiki, we should not be giving people fish (that makes no sense, I need sleep). I agree with the creating guides for typical roles of professions. I.e. (I mostly play a rit, so that's my example) under the Ritualist profession, we would have guides for "Restoration Ritualist", "Channeling Ritualist", "Spirit Spammer", "Minion Master" (and, as part of the minion master page, we would include minion bombing). These guides would provide information on how to play the role in a team setting, which skills are useful, etc. In addition, there should be a "Ritualist Farming" guide, with information on Khanhei Farming.

In reference to the "not having builds would disenfranchise a large chunk of the community" concept, I mainly agree with the statement "This is not a development and testing lab". The various GW forums are better for that (although, with regard to some, elitism and biases get in the way (the fact that no zergway build can be found on the GWG forums, and that whenever one asked for such a build, the thread was closed before info could be provided, comes to mind).

Again, I apologize for this late-night rant, and if I completely missed the purpose of this discussion (something I have an innate talent for doing with these things, apparently) I apologize (wow, that last sentence contained the phrase "I apologize" twice, neeeeeeeed sleeeeeeep). VegJed 23:31, 12 February 2007 (PST)

Any sort of untested, original, or experimental builds is a bad idea. Everyone posting their original build will think it was the greatest build ever invented. There aren't a lot of people who produce strong builds and there is an amazing amount of people who do not understand the game and produce bad builds. Any sort of original builds will just turn the official wiki into a repository of failed experiments. Look at all the people crying that they want to post their original builds of GuildWiki. GuildWiki's build section is a miserable failure and gets the entire wiki a reputation of being filled with noobs. The wiki is not where build development and discussion happen. If you want to discuss and develop builds go elsewhere. Original builds and ideas should be restricted to user spaces with maybe a buried page allowing people to link to their user space builds. This way when people post bad builds it reflects poorly on them, not the wiki. If you want to be creative, go somewhere else. Go post your builds on GuildWiki, GWOnline, or GWGuru. Anyways, if you ever invent a truly great build it will force its way into the metagame on its own and someone else will write an article on it.

Some quick examples of what happens with original builds:

-Warskull 11:29, 18 February 2007 (PST)

An early example

I just want to point to this page Starburster as an example why I hate the feeling of "I agree with you agreeing that we all agree that guides are great but we wont get anything done till christmas" I get when reading the talk page here. That page already has everything about buildes that can potentially go wrong in it:

  1. It is a simple collection of skills, without usage notes
  2. There is a battle whether that is a "good" build raging on the talk page
  3. It gets shot down because it is a bad build

The only positive point is that it has not degraded to name calling. Point 1 and point 3 should not happen (and point 2 somewhere else)! The wiki should NOT be a simple dictionary for builds and it should NOT rate builds (that includes deleting bad but frequently run builds!!). All this could easily be remidied with a sensible build policy, but that wont happen as long as there is a build witch hunt happening, when the real target should not be to hunt builds, but to avoid the drama around it.

So I challenge everyone to answer the question possed by Narcism at the very top of the talk page "Can we all agree that BUILDS WILL BE USEFUL to people visiting the site? and it's the implementation we'll need to be careful with." and then tell me what they dislike about the current proposal apart from the fact that it does not outright ban builds. --Xeeron 16:14, 12 February 2007 (PST)

I actually got so upset, I re-wrote the complete article. The old article is here. The current article Starburster (including the Starburster/AB Starburster subpage]]) shows how I feel guides and build should look like and work together in the wiki. --Xeeron 17:13, 12 February 2007 (PST)
This is yet another reason to have a historical section-both for guilds & builds. It's important for noobies to the game to go learn what a boonprot was and why it has disappeared.--Trevor Reznik 16:29, 12 February 2007 (PST)
I'm in agreement. As long we make it mandatory that all build-related must discuss and analyze the concept and role, we can reduce a lot of ignorant edits and comments and all the drama that comes with ego. And you can dump in history too if you want. (talk) 17:36, 12 February 2007 (PST)
I really don't see the point of presenting a full build article at all. The current Starburster article isn't too bad for something that covers a general type of elementalist, but I think the build subpage is pretty redundant: presenting an example skill bar to go with the article is fine, but all the other stuff is just unnecessary since it's not a GuildWiki-style build -- the guide itself should already tell you everything you need to know about equipment and strategy. — 130.58 (talk) 17:55, 12 February 2007 (PST)

I agree that point 1 should not happen. I disagree with you on point 3, I think that one should happen. Why should there be a page on the wiki suggesting readers to use a build or guide that doesn't actually work? Doesn't that get filed under "spreading misinformation" ? How can that be good for the wiki? On the other hand, this raises the issue, how do we decide which builds/guides are bad and which are good? There will need to be some quality check either way you want to call them. Obviously the author of Starburster disagreed with the others in the talk page, so distinguishing between them can't so easy. And this brings me to my next point.

I'm ok with the policy right now, which disallows all builds except those in personal user space and when used as examples, recommending guides instead. "Guides, not builds" is something that does seem somewhat less frightening, agreed. But there needs to be some more concrete criteria to distinguish between the two. "Guides have more words" is certainly not enough. I like your version of the Starburster page, remolded as a Guide instead of a Build, listing both the pros and cons and all that. But unless you tell everyone who wants to write a guide article "well, it should looks sorta kinda like the Starburster guide", then there need to be clear defined points of where a guide differs from a build.

And I'm still not convinced that even this will save us from the rage and drama. Thought experiment. Take a look at this guide that a user named Dirigible decided to post on the wiki today, and check the reactions that he got on the talk page of that guide. Practically speaking, what would you do in this case? --Dirigible 18:48, 12 February 2007 (PST)

Okay, I think folks are missing the point a bit:

The whole point of "Guides, not builds" is that Guides are not builds. I'm talking about something like the Invincimonk guide on Guildwiki or all those "how to do ____" guides on forums, not litte half-page articles that basically just recapitulate Guildwiki builds with uglier formatting. Most guides will not directly map onto builds at all. If you write a "build guide," you've just written a build -- not the point of this at all. Linebacker is a build, for example. Blindbacker is a build. Thumper and Infuser should be glossary definitions that link to more general articles rather than just builds that have been padded out a bit. — 130.58 (talk) 18:56, 12 February 2007 (PST)

I very well understand what would be the ideal build concept you mean, and actually fully agree with you that those particular types of articles would be a great thing. I'm just trying to say that there is a difference between the two, guides and builds, that needs to be expressed in a concise and concrete manner. I fully agree that we should have articles like the Invincimonk guide, and not like the Starburster or Frenzybot, which are really just builds with a different format, open to the exact same problems that the builds with the other format used to have. But we need to find a way to unequivocally distinguish between the two. A way to put it down in written form so that when a new user reads the policy, he immediately understands what a guide should contain and what it shouldn't contain. So, what makes them different? Wordiness? As you said, a build can be padded with a whole lot of words and still remain a build. Also, from the other direction, I doubt that all guides would be as extensive as the Invincimonk one was, so wordiness can't be it. And except for that vague intangible feature that Good Quality is, I can't think of any other way to express it. --Dirigible 19:48, 12 February 2007 (PST)
It doesn't matter if the build itself is good or not, only if the article is relevant. For the FrenzyBot, you'd ask that the article be moved to user space (or deleted) on the grounds that the FrenzyBot build is not in common usage, currently or in the past. It has no relevance to community, no more so than an article about radishes.
If someone posted an article entitled: "Radishes" and went into precise detail on how eating radishes improved one's ability to play ... what grounds would you have to delete such an article? Same with the FrenzyBot. No real relevance.
The point, in my mind, of "build guides" instead of "builds" is that instead of judging the build, you can judge the article.
Different example: There's an article on "Voice Coms". There's a section on Vent, there's a section on TS. I come in and add a section on "Drekmonger's Voicetopia 2000", a buggy voicecom program that crashes to desktop after 5 minutes. Twelve of my sockpuppets use it on a daily basis, and swear to god that it isn't loaded with trojans. How would you get that section out of "Voice Coms"? I honestly don't know, but whatever happens when wikis encounter problems like that can be applied to the FrenzyBot.
If there's a policy on no builds except in user space (in flashing red where the guild wiki vets will see it), then I'd hope such a situation would be rare.--Drekmonger 22:32, 12 February 2007 (PST)
But the thing is, a FrenzyBot article, even if it was the best article ever and the FrenzyBot was the best build ever, is still useless. We need textbooks, not answer keys: present a goal and how to approach it, not a solution. A good set of articles should enable a user to actually design his own build rather than to parrot someone else -- I don't want to see a player using "You're All Alone!" because some build page told her to, I want to see her using "You're All Alone!" because she understands how to use effective snaring techniques in various modes of PvP play. Because it's only in the second case that her decision is actually going to lead to her being able to use it correctly, and to weigh the other options (e.g. Cripshot, Crippling Sword, Shadow Prison, ice hexes) intelligently rather than just having to pick a build at random from a list. Examples are fine, but your article should be able to stand without them: if you can't deliver the bulk of the information without having to present a build or name specific skills, then you're not presenting enough of a theoretical and strategic framework for something to really be a good guide as far as I'm concerned. — 130.58 (talk) 01:14, 13 February 2007 (PST)
Frenzybot article is useless because it doesn't describe a common build. Frenzybot article is useless because it is an answer key and not a tutorial. But, if frenzybot were a common build (or a part of a family of common builds, such as GvG Warriors), then the article or the information within could be expanded, improved, moved to appropriate places.
In the meantime the Frenzybot article would be considered incomplete (a stub?).
Or deleted if consensus was that it described an irrelevant concept, just as an article on radishes or "Voicetopia 2000" should be.
"Examples are fine, but your article should be able to stand without them" is actually a pretty good sift to determine whether the article is a good tutorial instead of just a build description.

--Drekmonger 03:02, 13 February 2007 (PST)

  • Why there should be example builds: Imagine you played that starburster before, and now you are standing with 3 guildies in AB and everyone is going "gogogogo make a starburster quick", you hit guildwiki and find this page Starburster. Does it help you at all? Hardly. You knew the basic concept, but you want to know how to implement it. That is why there should be an example with attributes and equipment. It is on a subpage, because I dislike long articles.
  • Point3 and the Frenzybot: If there are enough people in the game who use Frenzybots, there should be a page here that explains what a Frenzybot is to people who want to know! It should explain how a Frenzybot works and why it has serious disadvantages. Your talk page example is set up, but we would deal the exact same way with someone putting in that Frenzybots are great as we would deal with someone changing the Ranger page to "Rangers pwn all!!!111". NOT by deleting the page, but by removing the POV stuff and making it better.
  • "We need textbooks, not answer keys": No, no and no. We are a wiki and not a textbook. If people come here looking for that information, they should find it. You are free to better the world by bettering GW players, but dont force your view on others. If those people come here not to get better, but to find the easy way, they should indeed find it. Using your rationale, I could also delete all mission walk throughs (we want people to get better, not follow wiki step-by-step guides) or skill page usage notes (people need to start thinking about that stuff for themselves, not mindlessly read it here). --Xeeron 03:25, 13 February 2007 (PST)
Textbooks have answer keys. But they do not require them, and an answer key by itself isn't a textbook. The crippling failure of Guildwiki's builds section, other than the voting policy, was the fact that all the information required to understand what a build was supposed to be doing and how it was designed was hidden away on a talk page, if it was present at all. If there were hundreds of articles about missions and half of them were really bad and a third of them created massive talkpage arguments and we had to suspend general wiki policy just to have a "missions" section then, yes, we would have to be doing this for missions as well. Yes, it's useful to be able to mindlessly read something off of a wiki -- but that article absolutely has to provide some help in thinking about it for yourself, too, simply because that's the only way to address the hidden assumptions and back-and-forth that ruined Guildwiki's build section. And having more generalized concept-oriented articles also removes much of the spirit of ownership that so dominated the Guildwiki build pages. — 130.58 (talk) 06:27, 13 February 2007 (PST)
I think the thing Drek added most recently expresses my sentiments exactly: if your article can't stand without a build in it, then it needs to be expanded or refactored. — 130.58 (talk) 06:36, 13 February 2007 (PST)

As Xeeron said: When I pay my quarterly visit to HA and the chat is full with "LF GTR!" (btw why is nobody using the party search?), then I will go to the wiki and I will expect to find out what GTR is, how it is played and what skills are used. I don't think it should matter whether it's a bad build or not. It exists, people are using it, we should document it. With skill listings, variants, guides, whatever is available. If it's outdated, say so on the page. Feel free to talk about the negative aspects of the build. All the problems with gwikis build section came from the fact that everybody was encouraged to add their own builds, relevant or not. If we don't want that, that's fine. But it's not a reason not to document helpful information about the meta game that is based on a good amount of facts, just because it involves builds. In short: The less relevant a build is, the more guide-like information should be required. An article about SF-builds with some basic information and a skill listing + variants should be enough to justify it's existence, it's specific enough. One about Rt Spirit Spammer Variant 14 not. Instead, merge those into a "How to play a spirit spammer in PVP guide". But I also see no reason why there shouldn't be a "Getting started with a Mesmer" article that mentions some very specific builds one could try out. DeepSearch 05:11, 14 February 2007 (PST)

A slightly different early example

Lineback is closer to what I had in mind than the starburster article. Debatable whether or not linebacking is a valid tactic. Not really the point. It's a known tactic, and the example builds have been seen in the wild.

A Nuke article with Starburster Searing lamer and Sandstormer might be a better example, since AoE eles are currently in fashion in HA.--Drekmonger 04:51, 13 February 2007 (PST)

That Starburster article is a build. It's so far removed from what I would consider a "guide" that I can't see a difference between a bunch of those and just "allowing builds". But as it stands, it's worse than gwiki as such stuff isn't even lumped in a namespace. Your Lineback example is exactly the way I think we should go forward. That way, build inside the main namespace are fully qualified by NPOV/factual/relevant content. Oblio 08:20, 13 February 2007 (PST)
I agree Drek. If we can classify builds we know into positional or tactical 'buckets' we can eliminate the profusion of builds which can occur which basically do the same things, but are dependant on what are the best skills at the time, or what someone thinks is better. How you play something like a Lineback, a 'nuker', or aggessive melee character in GvG doesn't change massively with the skills you use or what is best at the time and can be written with little reference to a specific builds and then a few of the more interesting or predominant builds can be included to provide examples.
Thinking on how this might work for PvE builds, perhaps articles should be grouped according to specific goals - so a build has to be attached to an article which is a howto for farming a particular area; So there could be an on how to be a spell immune 'tank' in DoA (I haven't been there I could be off mark with this) which could provide an overview of builds based on Assassin, Dervish or Elementalist skills which perform this task. This guide could link up to a Farming guide for the area which describes a frequently demanded team compositions for it.
I can still see that there is going to be some debate on the best example builds to include in the articles. But I'd hope that by being very general in the first instance many specific builds which come along can be eliminated based on "it's already covered". --Aspectacle 15:19, 13 February 2007 (PST)
I like the direction this is taking. I am for guides on roles and uses. That way, you don't have a series of Monk guides on healing and/or protting; and a series of Rit guides on resto Rits, channeling Rits, uhh... communing Rits? (I don't do rits here); and a series of guides on ele nukers, ele healers (I hear they are kinda common), ele... whatevers. Rather, you have a heal support guide that includes all Monk, Ele, Rit, Messie, maybe Dervish? healers. Then also, should one guide cover both Prot Monks and Heal Monks? I think so, most Monk Protters are healers too, and any build using Rit Resto skills will be since the skills in that line resemble both Monk Heal and Prot skills. So what roles are there? How many are there? What would be the best way to parse them (assuming we do roles rather than professions)? Heal Support; Interrupts Support; Damage Support; ect? I'm for "Support", because rarely does a build do only one thing. They often, as Prot Monk, do healing and support with Prots. Or Fear Me Wars, do damage and anti-caster support with Fear Me. If we do classify builds in position/role/tactical buckets, that seems the best way to do it to me. The main alternative, as I see it, is to just break it down into classes. So a warrior guide covering all types of warrior builds. But you can't have just one big page covering everything from Shock Axes to Steady Stances. The page would begin to break-down into the different support roles a warrior fills. But how many warrior builds do what a fear me warrior does? You can't really break a page down by secondaries, because what about all the non-secondary war builds? What about the secondary pages themselves? They would also bread down into different pages grouped by... roles. I think classyifying the guides by roles at the top will just simplify the whole hierarchical break-down of the guides.--Windjammer 23:07, 13 February 2007 (PST)
As for say, Interrupt support. For the PvP side, not required. Work off the interrupt article itself, imho. See that Fahna has already begun adding interrupt tactics to that article. An example build there wouldn't be out of place.
Healing would work the same way. Article on healing and/or protting, with a list of healing/protting skills and general truths about healing. An expert on healing includes tips for PvP monks and another section for PvE healbots. Then a few examples, such as the ZB monk and historic Prot Boon for PvP. (is there a common monk build in PvE? Everyone seems to use their own build afiak.)
Thumper makes sense to me in Knock down. Touch Ranger in Life Steal, maybe?
The constraints would be: the build must be a relevant example to the article, the build must be in common usage. So, a person couldn't/shouldn't add his pet build to knock down -- it needs to be an extremely common build to fit into a mechanics tutorial as an example. (and at least semi-common to fit into a tactics article such as Lineback)
Good idea to hang example off of game mechanic articles or bad? Anyone anticipate it becoming a huge mess, or can the examples be kept sparse?--Drekmonger 04:09, 14 February 2007 (PST)
I like the lineback article, but it is clearly not a build. All this discussion would be better placed at Guild Wars Wiki talk:Guides or maybe Category:Guides. --Xeeron 06:53, 14 February 2007 (PST)

Shorter proposal

Why do people come to the wiki to look for a build? Because they heard the build name in chat and want to know what that build is. We should give them this information. If they are comming here to see experimental new ideas, they are better off elsewhere. I tried to sum that idea up in the proposal. --Xeeron 07:08, 14 February 2007 (PST) PS: Something like this is what I would like when I look up a name I heard in chat here: Starburster. --Xeeron 08:52, 14 February 2007 (PST)

What happens when there's disagreement about a common build? It's a no-brainer that all general wiki policy should hold, of course... what I mean is this: is it better to pick the most canonical version of a build, the most effective, or present a handful of alternatives together? — 130.58 (talk) 07:29, 14 February 2007 (PST)
I don't think builds should be allowed except as examples as a discouragement against posting experimental or uncommon builds. All of the common builds a person needs to know about could be examples somewhere. If the builds are required as sub-pages to relevant articles, then all of these common examples would be available to someone searching (or browsing a category of builds.)
Thumper should be the model. Common canonical version(s), with possible variations listed.--Drekmonger 07:57, 14 February 2007 (PST)
A bit weird to stick that under Knock down, isn't it? — 130.58 (talk) 08:00, 14 February 2007 (PST)
Although the knock down article itself is a bit sparse, I've been using articles about game mechanics to hang tactical advice off of. See body block, interrupt, snares as examples of a game mechanic articles that also include tactical advice. Example builds would be a continuation of this. For knock down, the article could describe what a knock down is, lists skills that knock down, give some (advice on using knock downs effectively (or link to snare and interrupt), and examples of common builds that utilize knock downs. Thumpers have been, at least in PvP, very common knock specialists.
Doesn't really matter too much where the builds hang, imho. So long as they are relavent examples of common builds in a detailed article.
On the old wiki, you had an article about traps as a skill type, an excellent article about effective trapping, and a bunch of (mostly lame) trapping builds. I am proposing that all such articles would be hung off of trap, including common example trapping builds.--Drekmonger 08:17, 14 February 2007 (PST)

I don't think that's the only reason people come to the wiki for builds. Although to clarify that may cover it for PvP I don't know. For PvE I've used the Guild Wiki build section for various farming builds and running builds. In addition, though still in PvE, I can see where the DoA team build is also very useful. So, I'd like to see some of those included somewhere, be it in a guide section or a guide on farming or wherever. Lojiin 08:21, 14 February 2007 (PST)
I have to agree with both Xeeron and Lojiin. I know for me personally, I come to GWiki to find out what a PvP Build is and what it does, and I come here for PvE to find out exactly the skills and equipment used. At least for PvP builds I like having General Idea, Base Skills, Alternative Skills, Battle Behavior, and Disadvantages sections. That seems to me to get most of the information across as to what it is, what it does, how it does it, what it doesn't do, and how to beat it. --Vindexus 08:41, 14 February 2007 (PST)
But you do see some interesting build names in chat (As Vindexus' TTN demonstrates!) :) Extend the proposal to specify different info to be captured and defined acceptability depending on the purpose?
For PvP builds I'd like to say something like regularly visible in observer mode GvG or infamously known from HA to restrict the possible example builds further. A PvP build's description should be generic; as other have said Thumper seems a good example as it discusses variants but core skills are clear.
Specifics of Farming/Running PvE builds are important so the rules around that should be different; allowing Attribute Point distribution to be specified, armour to be suggested. I'd expect to see this sort of build listed and clearly accepted in the guildwarsguru farming forums *first*.
I don't know about General PvE, maybe if it were attached to a guide and was made to be of a general nature like the PvP builds it could be workable to allow these builds without too much pain. --Aspectacle 15:03, 14 February 2007 (PST)
Unfortunately "infamously known from HA" is far from being an objective criterion and observer mode only convers one of many game modes. However, if it is infamous, it will be used in often in chat. Btw, I never read TTN in chat before, so it must not have had its commonness come round to my end of the world yet ;-)
Regarding farming builds, the current policy does not rule out stating exact attribute points (though I have to say that I would always push for these being listed on a separate example sub-page to the main article).
I used "mentioned in chat" as a rule of thumb, but it really boils down to determining whether the build is an existing common one (where I guess the existing part can be taken for granted if it is shown to be common, lol). --Xeeron 15:44, 14 February 2007 (PST)
Sorry, TTN is a project of Vindexus "Talking to Noobs" a collection of interesting things said by people in Guild Wars - not a Build. Sorry for the confusion! :)
I agree with your short policy really, I understand the spirit in which is it proposed. I just think that it'd be easier to police if allowable ("existing common") builds follow a stricter set of rules. Part of the fracas about the Starburster build was that we each have a different notion of what common is. Searing Flames is more common now in HA and GvG, much of the description and the reasons they're run are *exactly* the same. The refactoring computer programmer in me begs for abstraction and consolidation of the bits which are the same, so we can capture the more common build and the now less common build in the same place. But perhaps that is build format not policy?
I know that infamy isn't objective, but neither is common, but it does imply a very high level of community awareness of the build. Plus the definition of Infamy doesn't have to be just in HA. I'm intentionally trying to set the bar high and rule out some areas - I just don't see that capturing info on common RA builds (which are almost as random as the teams you end up in) is very important or should be encouraged. --Aspectacle 19:50, 14 February 2007 (PST)

Build name space

There is no mention of a build name space in the policy. I hope there is going to be a name space if builds are going to be accepted. -- Gem (gem / talk) 23:22, 14 February 2007 (PST)

I am agnostic on a build name space. If others want it, fine, if others think it is not needed, fine as well. But either way, I feel that is a question for Guild Wars Wiki:Formatting/Builds, not the policy page (like the consolidation mentioned by Aspectacle above). --Xeeron 03:16, 15 February 2007 (PST)
There really shouldn't be a build namespace, I think. In this framework, only common builds are listed, and the process is descriptive, not perscriptive. As such, they fit in with regular articles just fine. — 130.58 (talk) 04:23, 15 February 2007 (PST)
I am against a build namespace also. I think of namespaces as fences around content. Currently there is a good reason to fence guilds in -- they are a whole new ball of wax that we know (and can predict) very little about. With builds, we have a year and half of experience and we know exactly what doesn't work in a wiki setting. We can be a bit bolder with them. S 04:33, 15 February 2007 (PST)
I, too, am against a build namespace. With the GuildWiki we agreed to the build namespace so that we could safely treat them as separate content. I would sincerely hope that any policy we allow on builds would mean that we didn't need that. LordBiro 06:47, 15 February 2007 (PST)

Man all this discussion on what should and shouldn't be allowed for builds is going on forever. I still don't see why not just let people create builds. It isn't like they are making up things, builds are options people use.... facts... even if they aren't popular. Also, it if is because you guys think it is a "moderating nightmare" then don't watch or moderate them. As it stands right now, I think you are going to spend more time policing builds to see if they fit the standards, than if you just let them happen. Hell, the amount of time just put into this discussion would have been enough to edit the builds pages for months. --RabiesTurtle 08:46, 18 February 2007 (PST)

The names of all your characters are also a "fact," but we don't write articles about them. Builds that aren't actually widely used are irrelevant. A wiki is supposed to be a useful reference, not a message board or a free webhost. Builds are hands-down the worst thing about Guildwiki: you have to dig through a lot of crap to get to a decent article, and that article offers you minimal information about good techniques for actually using the build. And you have 100 copies of the same damn build, and people people favoring all kinds of crap builds, and people cursing each other out over builds. And it's all useless. Especially because what should be the juicy part of the article is instead either nonexistant or hidden away on the talk page. Why repeat all that bull here?
Articles on how to run a spike warrior, a pressure warrior, a gank warrior, a PvE tank, and a PvE damage spammer, with appropriate examples, are useful. An article about some guy's random dagger-warrior build is not. All IW builds can be represented in one article. All Sliver Armor farmer strategies can be represented in one article. All 55 builds can be explained in one article. Ditto for DragonSlashers, minion masters, YAA spammers, echo nukers, Barragers, Orders spammers, and any other thing you can think of: one good, sensible, detailed, objective, example-rich article for each archetype. — 130.58 (talk) 17:43, 18 February 2007 (PST)
Guides are Good, Builds are Bad is a fine mantra, but we'll need a good set of standards behind it for it to work. For example, the General Minion Mastery Guide is, in my opinion, far too long to be genuinely useful. At the moment it's almost just an extended set of skill and armour descriptions, listing almost everything that could conceivably be useful for a MM (people already have everything in game, what they need is focussed guidance on core stuff). On the other hand I'm only aware of a couple of types of Orders spammer (Fast Casting Mesmer and PvE Necro Battery), so in comparison that'd come out as a rather thin guide. We need to work out policies/formatting etc for guides just as much as we do for builds - pushing guides over builds is only redecorating the problem, not actually solving it. --NieA7 02:45, 19 February 2007 (PST)
Agreed. The things I describe above, however, could be represented as Guildwiki "build" articles, too. Just a bar with a few optional slots and a lot of variants. The point above wasn't about guides-vs.-builds per se -- it was about how most builds are trivial variations on a theme, clones of clones of clones that work no better than the original. Moreover, one thing that Guildwiki makes absolutely clear is that most alterations to a build are a lateral shift: it honestly doesn't matter what you put on the 7th slot of an SS necro or what a Renewal nuker is casting in between spamming MS every 15 seconds or whether you use Flurry or Frenzy on a Choking Gas ranger. Guildwiki-style build articles -- in fact, any place for builds that still features implied ownership -- is going to have a lot of arguments about trivial, lateral changes. Any place where everybody comes along and posts his warrior's skill bar is going to have hundreds of variations on the same exact thing. Most build threads on forums are only going to be majorly useful to the poster, since he'll get some feedback about his play. That part doesn't happen on a wiki. So, the majority of builds you'd put on a forum... don't need to be on a wiki. — 130.58 (talk) 06:03, 19 February 2007 (PST)
"Builds that aren't actually widely used are irrelevant" ... See, this is where I disagree. When I want some new ideas for a profession, I go to the build category, and open every single build for that profession in new tabs, and glance through them. I don't usually use a build exactly as is, but it gives me ideas of some interesting combinations. Heck, I usually make even better builds from them. This is why they are very useful for reference. There are hundreds of skills out there, and I don't believe that just because some unimaginative people use the "typically used" builds means that the wiki shouldn't provide at least some incite into other ideas. Even the best "guide" isn't going to be able to suggest odd combinations. Common maybe, but nothing interesting. If I want to learn how to do the basics of the game if I am a noob, then a guide is great. If I am trying to come up with something new and my own after mastering the basics, then build ideas from hundreds of players takes the cake. If the complaint for builds is that sometimes builds are similar... fine, we should focus on making those differences as variants for the common skillset.
I guess one way to look at builds is from a programming perspective. Think about all the sources where people submit little bits of code and you use it as a resource in your own project. You might not use it exactly, but it gives you ideas. However, if your resources only supplied the basic functions, it isn't really going to help any. Same concept applies to builds, there are infinite solutions... so having people post some that seem to work narrows the field and promotes ideas. The wiki is about reference and knowledge of the game... kinda the same idea isn't it? --RabiesTurtle 20:23, 19 February 2007 (PST)
To be honest, from a programming perspective, I mostly disagree. Random snippets of code may occasionally be useful, but they're a total nightmare when people shove them in between the pages of a reference or tutorial. And they're never as important as an actual reference. Being able to look at man pages is vital, being able to download some guy's fully-functional optimized implementation of a critical algorithm is vital, being able to look at someone's half-finished first draft... not so much. Or, when it is useful, it's best in a forum-like environment, with lots of people commenting to offer information and ideas, such that the real knowledge gain comes not from the original snippet but all the discussion. Guildwiki has shown that wikis handle build discussion poorly.
Heck, when Nightfall came out, all the coolest skill combos were already written up on skill's Talk pages long before any builds using them actually made it to Guildwiki. — 130.58 (talk) 18:24, 20 February 2007 (PST)
They aren't thrown in though... they are in a separate section. You also mention forum environment and talk pages... I don't know about you, but there are a ton more skill talk pages than builds which makes it impossible to just randomly discover someone's new idea. And wiki doesn't have forums anyway, so why not at least have the style wiki can offer? Back to the programming comparison, even if you think that you don't learn as well from build examples than the reference pages, don't you think there are likely some out there who learn differently? Why not have the ability to reference ideas by both methods? — RabiesTurtle 22:08, 20 February 2007 (PST)
I can understand the argument that common and significant builds should be listed on the GuildWiki or this wiki. The wiki is a reference tool and therefore if someone has a query about a build we should be able to answer it.
I cannot understand the argument that new and innovative builds should be listed on either wiki. As a reference tool we have no need to document builds that people will not ask questions about. If you want to make new builds then go ahead, but I don't think either wiki should be the place for them.
I realise that by only documenting common and significant builds we may not provide ideas or inspiration to new build authors, and this is something that I will not lose sleep over. LordBiro 04:50, 21 February 2007 (PST)
Every big GW forum has a section for getting comments on your build. There are websites that just host builds, too. Going by the programming example, what you're asking for is like adding a special Man 10 that just contains random junk code to the Man pages -- yeah, sure, it's contained in its own section, but it shouldn't be in Man at all. — 130.58 (talk) 05:35, 21 February 2007 (PST)

lol, please stop with the programming analogy :P LordBiro 07:28, 21 February 2007 (PST)

Haha, fine by me. I guess what I see here though in this thread (especially below) is that the solution to the problem of people posting builds... is even more complicated than the original issue. It seems like we would have to be debating if a build is common, useful, etc so much for the builds that it would be more work than simply letting people post their builds themselves. I do like the idea for the basic guides, I just don't see what the harm could be in letting people do builds too. Clutter? I don't see it that way since they were organized enough by category and you don't even have to see them if you don't want to. Moderation nightmare? So far the solutions offered would be much more moderator intensive. — RabiesTurtle 09:27, 21 February 2007 (PST)

Builds of Historical Significance

I'm thinking that this should be more specific on what would fit under that. I have a rough idea but not one well-stated enough to place in there. I'm guessing that it'd be outdated builds that were formerly popular but aren't viable anymore due to skill changes (55/SB would be one, I suppose). Including a reason why would help people who come along and may want to rework an outdated build. Old cookiecutter(? - forgot the common term) PvP builds that GW used to include along with the creation of PvP character would work too.

My intention was that the historic builds should have the same criteria for inclusion as current builds except for the fact that they met the criteria in the past(!), but it must be stated clearly that the build doesn't work. Do you think that there is more info required or that this needs to be explicitly stated? --Aspectacle 15:46, 18 February 2007 (PST)

Builds and Guides questionnaire, by GrammarNazi. PARTICIPATE PLEASE! :P

Below is Grammar's questionnaire. Please add comments in the format "<Answer>, <rationale>, <optional conclusion>" . Most importantly, add your opinion in isolation of others ('Bob said this, and I disagree because'). Treat these questions as if you are taking a test - don't look at other answers; doing this will ensure that the questionnaire shows strictly people's own individual opinion in numeric form. Additionally, GIVE SUGGESTIONS where applicable. Lastly, keep your answers as short as possible, and do not disrupt chronology.

  • Do you believe the format/policies for GuildWiki builds is/are okay to use here? Why or why not?
  • Do you find that GuildWiki generally provides HELPFUL, POINTED, and ENGAGING articles regarding the use of Skills/Builds, or TOO LITTLE, INACCURATE, or IRRELEVANT information regarding Skills/Builds? Why?
  • On a rating of 1 to 10, 10 being the highest, how strongly are you for or against implementing a modified, or otherwise completely different system (ie, "guides") on Official Wiki (henceforth, OW)? Why or why not?
  • If you believe a different system entirely should be implemented, please give a concise explanation of your rationale and your idea.
  • If you believe a build or guide section is appropriate on OW: On a rating of 1 to 10, how much moderation, if any, should OW exact on a future builds or guides section or sections? Explain your answer.

Thanks for participating, hopefully this questionnaire helps expedite this discussion. Before you add questions, please leave a message on Talk so I can word it as unbiased as I can.

GrammarNazi 10:35, 18 February 2007 (PST)

Were we so far from concensus that we have to rehash much of the discussion above? My impression was that builds would be allowable, but that wiki would only document common builds (eliminating experimental aspects, build voting and trial and error from Gwiki implementation which seems to be the root of the disapproval of the previous system) - the policy currently on the page says as much. What is still open for debate is what exactly consistutes a Guide, what consistutes a Build in people's minds, basically the level at which a build should be documented - I guess it boils down to whether a GWbuild article which is more general and has more actual useful information about the build (such as Thumper) is the sort of page we want to head for. And that discussion *could be* left for a discussion on the formatting of the article - if we can agree under what circumstances a build article should be allowed to be created in the first place. Of course I could have misinterpreted the discussions so far on the page. :) --Aspectacle 16:15, 18 February 2007 (PST)

Hehe, well the very reason you found room for doubt in your own interpretation of this page, is the same reason that I posted this mini questionnaire. I wanted to get a more organized, easy to interpret understanding of what the community thinks. Haha :) As far as addressing specific details in your discussion above - I guess it boils down to ...more general...actual useful information about the build... I intended to design the second and third question to help answer this. If we know why GWiki is insufficient, and we have some very brief, clear insight on what people want, it will be much easier to come to an agreement. At least, thats how I've seen it :) GrammarNazi 21:48, 18 February 2007 (PST)

Answers from Cynical

  • Do you believe the format/policies for GuildWiki builds is/are okay to use here? Why or why not?
Yes. I think the general policy (that any viable build can be included) is fine, but we need to modify it slightly. For example, GuildWiki currently has FIVE minion master builds for 'general PvE' usage. All five builds use the following format: two minion summoning skills, a minion healing skill, a master healing skill, and one of either Flesh Golem or Aura of the Lich.
I would much rather that we aim to have a single comprehensive Minion Master build page (detailing the different options - AFG vs AoTL, Shambling Horrors vs Vampiric Horrors, Blood of the Master vs Healing Prayers etc.), a single Burning Arrow Ranger build page, etc. This way, people wanting to learn a particular build would only need to read one page, and could decide which variant was best for them
  • Do you find that GuildWiki generally provides HELPFUL, POINTED, and ENGAGING articles regarding the use of Skills/Builds, or TOO LITTLE, INACCURATE, or IRRELEVANT information regarding Skills/Builds? Why?
I think the problem with GuildWiki is that build pages tend to be separate kingdoms. There can be multiple different builds (see my above example) which all do exactly the same thing (albeit in slightly different ways) and these will be dealt with in their own separate pages, with much of the development work being duplicated. It would be better if all the people who use Minion Master builds (just to keep that example going) worked on a single Minion Master build page, which would give us one very good page instead of a couple of good ones and a couple of not-so-good ones.
  • On a rating of 1 to 10, 10 being the highest, how strongly are you for or against implementing a modified, or otherwise completely different system (ie, "guides") on Official Wiki (henceforth, OW)? Why or why not?
8 against. From what I've read above, a 'guide' system would only detail the very, very popular builds (such as a 55, or a Barrager). Nobody really needs a Wiki to tell them about these uber-popular builds - you can learn how to make a 55 or a Barrager by asking 'What is a ...' in alliance chat. If a build is useful (see my suffrage comments below) then we should have an article on it, otherwise the users (who want builds) will continue using Guildwiki instead of OW.
  • If you believe a different system entirely should be implemented, please give a concise explanation of your rationale and your idea.
I think we should have a builds section, but without any duplication. Like I said above, we should not reject a particular build based on some pie-in-the-sky 'frequently requested by name in either PvE or PvP outposts.' (I have been playing Guild Wars since release and have NEVER seen ANYONE asking for a build by name in an outpost).
  • If you believe a build or guide section is appropriate on OW: On a rating of 1 to 10, how much moderation, if any, should OW exact on a future builds or guides section or sections? Explain your answer.
6. I think we should enforce the 'one of each build' requirement I suggested quite vigorously - if someone posts a second Minion Master build page, for example, then admins should shoot on sight and suggest that the person contribute to the existing page instead.
I think that the GuildWiki 'build approval' system could work (as opposed to pre-moderating every build submission, which would require an extraordinary amount of time and an even more extraordinary number of admins), but only if we have a 'suffrage' requirement to prevent the sort of meatpuppetry that people have complained about as regards GuildWiki. Something like having to have contributed for X months and have Y edits, before your opinion on the viability of a build can be counted.
I also think that disapproved builds should be deleted rather than put in an archive category - if the community has decided that something is useless, why have a page on it? The only exception to this should be for really popular builds which are no longer used (I'm thinking of a Spirit Bonder, there are others), as a sort of record of how Guild Wars has developed.

Skuld's babble

  • Do you believe the format/policies for GuildWiki builds is/are okay to use here? Why or why not?
    Obviously not. It failed miserably on GuildWiki and very little positive came from it. It attracted the wrong kind of people, not ones who want to contribute, the ones that want their build on the net and some free hosting. The GuildWiki system was far too lax, anything could get through and no-one was willing to delete even the most obvious trash, it just got stuck in an "unfavoured" category. The system will never work when the cocky pre-searing grad has an equal say to ensign when it comes to marking up what is wheat and what is chaff, and a wiki is all about people having a fairly equal say, therefore a wiki is a very bad format for this sort of thing.
  • Do you find that GuildWiki generally provides HELPFUL, POINTED, and ENGAGING articles regarding the use of Skills/Builds, or TOO LITTLE, INACCURATE, or IRRELEVANT information regarding Skills/Builds? Why?
    Far too little. You have all the stats, now what? I equip all my skills and run out into the battle, activate healing signet, frenzy, shock myself to exhaustion and go and aggro the whole map. The whole thing was bogged down in trash, for every good character build, there was 100-200 pages of trash.
  • On a rating of 1 to 10, 10 being the highest, how strongly are you for or against implementing a modified, or otherwise completely different system (ie, "guides") on Official Wiki (henceforth, OW)? Why or why not?
    1/10. We should document the game with hard facts, not the questionable wisdom of some. You wouldn't write a book without researching, why should you start an article if you don't understand even the basics of the game.
  • If you believe a different system entirely should be implemented, please give a concise explanation of your rationale and your idea.
    No builds.
  • If you believe a build or guide section is appropriate on OW: On a rating of 1 to 10, how much moderation, if any, should OW exact on a future builds or guides section or sections? Explain your answer.
    Not worth it. The bar of people who grasp even the game basics is far too low and this is a harmful waste of time to even contemplate a "builds" system.

This isn't intending to come off as bitter, but it may sound it ;p — Skuld 09:32, 26 February 2007 (EST)

Haha. Oh Skuld. Thanks for your response btw. GrammarNazi 15:23, 27 February 2007 (EST)

Post No Builds, Ever

If you want this OFFICAL wiki to fall upon factual information, No Build Section. Having to refer to other locations for 'farming builds' is subjective as it what people see as is Observer mode.

If you want to help people produce builds, we just need a general stragety guide toward approaching the production of a build within the domain that it rests. There can be a build guide for GvG, RA, TA, AB, HA, PvE, PvE Farming, and the like.

Finally, as a factual helping hand for those who want to make builds, synergy notes should be listed in their own section on all the skills in the game. This will allow players to automatically see which skill works with another, so they're guided to produce sound builds. I've seen too much nonsense by people in the build section in the past, and I frankly do not think any slightly subjective system is good in the future as it produces temptation for douchery.

If people want -exact- build information for someones build, they can go to the private page or look around the net for it, be it good or bad. Or they can just go to Observer mode in game, if they want to Observe some guys build. Otherwise, leave BUILDS out of the wiki. Isis In De Nile 05:55, 19 February 2007 (PST)

As was discussed more towards the top of this page, it was generally agreed that there is a community interest in having a build section on the wiki. People will come here looking for that information and it seems to be a natural expectation. That being the case I think we should include the section and the currently proposed policy I think could work with a little clarification on what the term "common" means and when a PvE build for farming should be included. Lojiin 09:29, 19 February 2007 (PST)
Or to be more precise, builds have merit on this wiki, though perhaps not in a "section". My personal current position on builds is that we can't come up with a criteria for allowance of builds until we come up with a policy on deletion ( read : Guild_Wars_Wiki:Speedy_deletion, GWW:DP intentionally red). When we know what qualifies an article as "unneeded on this wiki", then we can talk about how to differentiate between useful build articles and unuseful ones. Until then, any build policy will be incomplete. Oblio 11:35, 19 February 2007 (PST)

I've seen too much nonsense by people in the build section in the past, and I frankly do not think any slightly subjective system is good in the future as it produces temptation for douchery. Remove the GWiki's vote-upgrading system, and you remove the hassle of moderators on overtime, heated debates, and douchery; build sections without this common thread simply becomes depositories for new ideas, and assuming this section was labeled as such, would be VERY easy to implement and maintain.

The GWiki build system's "nonsense" builds are almost always created by someone who doesn't have the experience necessary to create a build. However, their inexperience seldom means that they're un-willing to revise or completely delete their build pages. Often they post more to get advice than to show their "pwnage" build which some people take pleasure in laughing at.

Oblio, removing the build section's strange and convoluted vote system and giving Build authors more control over their page would obsolete the necessity to differentiate. At the very least, I believe doing this would be worth trying to see how it goes. I think one thing people need to realize is that nothing determined now has to be set in stone for the rest of eternity. We can test something out, and if it doesn't go well, do something else :) GrammarNazi 11:51, 19 February 2007 (PST)

While I'd agree that removing the voting system would remove alot of the hassle I think having a large number of builds that are of lower quality will reduce the usefulness of the build section. Considering someone could simply upload a build with 7 copies of mending and a rez sig which is an extreme example of an obviously unuseful build. In the case of the currently written policy such builds would be restricted to user space. Perhaps people could add a category indicating they'd like feedback on it so if they want help people who check for that category could see it and if people didn't care for builds they could just not bother to look. In such a case the main buildspace would be restricted as currently noted in this policy. Lojiin 12:38, 19 February 2007 (PST)
I can still see that there is going to need to be some moderation of builds written, regardless of what scheme we end up in... someone is going to have to make the call to what is common or not and whether a new build is sufficiently included in an article somewhere else. I suggest someone who isn't too soft-hearted or inclusionist. ;) If they saw a build like the one you described it should be moved to the user space or deleted immediately - no question. Perhaps the policy should indicate this, and perhaps indicate that builds articles could be split or merged depending on the similarity of the variants? I do like the idea of the category which could allow for feedback on userspace based builds - for those who feel the need to experiment with such things in a public place.
Also a backtrack on the 'conversation' you suggest that we could modify the policy to better indicate which PvE farming builds could be included - do you have any ideas for this? All I can think of to remove the fan site requirement in favour of the commonly used and having a seperate section which states that farming builds should be grouped according to the area/thing farmed, rather than by profession? What's on the policy page atm is my best guess at trying to reduce the scope of possibly included farming builds without some help. :) --Aspectacle 14:40, 19 February 2007 (PST)
Lojinn - Extreme and intentionally bad build pages are easily recognized and deleted - they always have been, since those are under the category of vandalism (at least I would consider it that). In regards to the "lower quality" builds - Echo Mending aside - the relevancy of quality decreases when one takes into account the lack of an "upgrade by vote" system. If all builds are treated "as is", and constructive criticism is not mandated, but merely allowed, then users will understand that the Build section is a collection of ideas instead of a cheesy tome of prescribed setups.
In my opinion, the users who want to post builds in order to receive constructive criticism ought to continue having the right to receive it. I think its silly to simply omit a build section entirely when there is a great potential for experimentation that everyone can participate in and learn from without (no offense here) moderators going on deleting rampages.
On the other hand, I also think that the Guide/Concept section should be in the foreground, and that this really cannot be challenged. Having a Guide section of well-established setups and strategies is just flatout a good idea and needed to happen sooner. ::::I was going to reply to Aspect but I am le tired. <3. GrammarNazi 20:43, 19 February 2007 (PST)
Yes, I agree that such a thing could/would be deleted. However, that means that there has to be some basic criteria for deletion. Such as A) An impossible build. B) Completely non-sensical build. (i.e. echo mending). Where if there is any doubt in case B) the page should be left and discussed. It seems, then, that we want to have sort of a two tiered system. The first/primary tier would be as defined in this policy currently. That is, common builds referenced by name for PvP, and similarly for PvE with the addition of farming/running builds. Farming/running builds are easy to rate as there's a quantifiable metric for their success and most often they can be found on other forums as well. These, the farming/running builds, would be limited as well to known useful/proven builds. Tier 2, then, is more of the build playground. Keep it a level deeper, or keep it in the user space and add a category. The implementation can be debated. In this section people can post builds as they choose and get feedback on them. There is no vetting process. Builds do not move from Tier 2 to tier 1 unless they meet the tier 1 criteria. That is, they become common. (Or for farming/running builds, they are proven to be useful, functional builds.) Tier 1 can also be kept to guides. For most to all of the common builds a more detailed explanation with benefits and drawbacks would be useful, though I think sub-pages with specific implementations are also helpful as people at some point will come looking for those.
Re: Aspect's question on how to remove the other fan-site requirement or ideas on what farming builds to include. Generally speaking I haven't seen alot of issue with farming builds. They either work, or they don't. The only questions that I usually see crop up are : something else does it faster. I think, though, that the only important criteria for inclusion would be is it functional where functional also includes reasonable effectiveness. For example I could build a totally defensive earth ele build with stone daggers and call it a vermin farming build. Would it work? Most likely. Would it be functional? Not really. It'd take me several minutes to kill 1 group of vermin. As far as grouping goes, I think we should keep them grouped by profession not by what they're farming though with categories I suppose both could be done. For running builds similar criteria apply, is it functional? Can I make the run the build was designed for? Or in general cases, can I run with this build? A ranger running build, for example can be used in many places but its effectiveness is easily proven by using it in one or two examples. Lojiin 10:36, 20 February 2007 (PST)
The very idea of "build author" is incompatible with the idea of "wiki". — 130.58 (talk) 18:09, 20 February 2007 (PST)

Sorry in advance for repost. "It seems, then, that we want to have sort of a two tiered system. The first/primary tier would be as defined in this policy currently. That is, common builds referenced by name for PvP, and similarly for PvE with the addition of farming/running builds. Farming/running builds are easy to rate as there's a quantifiable metric for their success and most often they can be found on other forums as well. These, the farming/running builds, would be limited as well to known useful/proven builds. Tier 2, then, is more of the build playground. Keep it a level deeper, or keep it in the user space and add a category. The implementation can be debated. In this section people can post builds as they choose and get feedback on them. There is no vetting process. Builds do not move from Tier 2 to tier 1 unless they meet the tier 1 criteria. That is, they become common. (Or for farming/running builds, they are proven to be useful, functional builds.) Tier 1 can also be kept to guides. For most to all of the common builds a more detailed explanation with benefits and drawbacks would be useful, though I think sub-pages with specific implementations are also helpful as people at some point will come looking for those." I find this to be a fantastic approach, Lojinn. GrammarNazi 13:58, 20 February 2007 (PST)

A big fat line needs to be drawn between what is known to work and is common and what *may* work or might not work well. If tiers are used keep the unconfirmed builds in the user space; keep the wiki/info space clean. Provide categories to get visibility for userspace builds and get feedback, but they should be kept seperate. This policy should not endorse experimental or sub-par builds or sub-written-quality build articles in the official info space - for simplicities sake. A tier system could be used to help with internal builds (particularly farming/running), but I don't think that all builds(particularly those at Thumper detail) should necessarily have to go through the tier system to be included. If someone puts a well written common build straight into the information space I don't want to see it rejected because it didn't jump through the hoops, but meets all other criteria.
I don't see how this is much different from what is listed on the policy already; perhaps a little more detail around user space builds and specifying the categories available. Maybe moving the farming(when I say farming I mean running too, m'kay?) stuff from "commonly used" to "most effective" and generalised by farming area rather than by profession. Otherwise... yea sounds ok. --Aspectacle 15:16, 20 February 2007 (PST)
Just to note, there's nothing saying that a build has to move from the 2nd Tier (user tier) to get into the first tier. Actually, I think I suggested that in general builds would not move between tiers. If a build meets the criteria for tier 1, it goes in tier 1. If it just so happens that it currently exists in tier 2 then it happens to. If not, then not. Lojiin 15:21, 20 February 2007 (PST)
If you formalize a method by which builds move from the user space to the main namespace, then I don't look forward to some of the arguments that are going to come. Even with farming builds, imagine all the degen-ranger variants for everything. The idea of letting people put builds in their user space is fine. The idea of adding a category to facilitate inter-user-build dialog is fine. But my position is that what goes in the main namespace is factual information only. I don't even like the idea of having farming builds that "work" in that namespace, unless they are so common that they are referred to by name in the community. But I'll simply reiterate my earlier point, until we have standards for relevancy and quality of a normal article, then we can't really have standards for build articles (a subset). Oblio 07:39, 21 February 2007 (PST)
Oblio, while I appreciate your concern, I would like to point out what I said above in my suggestion. That is : Builds do NOT move between tiers. If a build is common (let's say SF nuker for example) then it belongs in the first tier and should be documented there. Now let's say that I happen to have a version of the SF Nuker build in my userspace to play around with, adapt, etc. The fact that I have a copy there has nothing to do with whether or not the first tier should have an SF Nuker guide. The SF Nuker is a commonly used build, therefore it meets the criteria for tier 1. Thus, someone, be that me or you or anyone else, can writeup a guide and place it, correctly, in the tier 1 space. It doesn't have to pass through tier 2, it doesn't matter that I, or anyone else, has a copy in the tier 2 space. It meets the tier 1 criteria so it can go into that space. Lojiin 08:51, 21 February 2007 (PST)
Nothing to add but that I continue to agree with you Lojiin. :P GrammarNazi 22:13, 22 February 2007 (EST)

Proven to be effective

I have deleted that part from the policy, here is my reason for that. The part about proven to be effective lacked one important criteria: "better than other builds". My echo mending sword monk is perfectly effective for farming grawl, but ten times slower than good builds. However the criteria "better than other builds" is almost impossible to valuate and would result in ugly rows over how effective the build actually is. Even for farming builds: If the build is common, we should have it, if it is not, we shouldn't. --Xeeron 05:31, 23 February 2007 (EST)

As I noted above I agree that "effective" needs to have some inclusion on how well it works vs other builds. As this is potentially quite a contentious point I don't disagree with the removal. However, the question I then have is: When is a farming build considered common (that is when does it qualify for inclusion)? Since farming builds are meant to be run solo for the most part, people won't be asking about them in outposts. Exceptions of course being things like trap groups but in general that holds true. So when does a solo farming build qualify as common? Certainly some builds like the 55 monk, would qualify at the beginning but for new builds at what point is that considered common? Will community consensus work for that? Given that there's a quantifiable metric for farming builds I expect it to be less of a problem than general builds, but I think that it does need to be specified. Lojiin 11:45, 23 February 2007 (EST)
Farming builds are usually discussed on forums instead of ingame. When I removed proven, I added a bullet point about being frequently discussed on user forums. That one should capture farming builds. --Xeeron 15:07, 23 February 2007 (EST)
I like the first part of the policy as it is at the moment. The edits Xeeron made cleared some reservations I had about the farming builds stuff, and the possiblity of proliferation there. The most effective builds are going to be commonly discussed. --Aspectacle 18:21, 23 February 2007 (EST)

Discussion on policy as written

There are two things which I'm concerned about with the current policy wording as it stands;

  • may allow up to three complete builds
  • the entire user builds section

So for the first I just pulled 3 from the air as not sound too much or too little, but we haven't really discussed it, what do y'all think?

And the user build section, by having this section are we encouraging what happened on Guild Wiki, but just in the user section rather than the build section. Would it be best to remove the temptation for people to try and do that by removing at least the Feedback category (sure I added it in the first place, but I'm having second thoughts), or possibly the section all together? --Aspectacle 18:21, 23 February 2007 (EST)

In my opinion, I don't think we need to indicate a number, min or max, of complete builds per guide. If there are 5 major variants (in theory yes? Bear with me here.) They they can be listed. If there's only 1, then list 1. I think the user builds section is fine and workable. If the user wants feedback they can get it. If they don't, or dislike feedback the they're getting (i.e. get offended), they can remove the category from the page and go along their merry way. Note that the Feedback category is not about getting good builds to potentially move. Its about people asking for input. There's no voting on said section, though I suppose if an author felt like putting one on their user space they could do that (it just wouldn't serve any official purpose). For that reason, I really don't think it'll end up like the current GuildWiki build section. It can actually be a great benefit to people who want to know how to create better builds or just want better builds for themselves overall. Lojiin 18:28, 23 February 2007 (EST)
Well, if there are 5 major variants, then list 3 complete builds and mention the remaining 2 briefly. I think, from the wording, it does not restrict how many variants you list, just restricts how many complete builds you are allowed to post. But then again, this limit is pointless. It doesn't really help much and if there are too many variant complete builds listed out, we can simply merge them, remove the complete build, and explain the variant instead. As for private builds, I am totally against the idea of even attempting to make them more visible. It'll erupt like GuildWiki all over again. This is a wiki, meant to document the game. This is not a forum where users post their builds and look for feedback. If they want feedback, they should go post in a forum. I see absolutely no reason to encourage discussion on individual builds that contribute nothing to the Wiki. -- 21:17, 23 February 2007 (EST)
The number 3 seems to be a bit redundant to me, but I dont mind it. Whether we say ""only use the most common variants as examples" or whether we give a fixed number max should have a very similar result. The first seems to be somewhat more logical (since some builds might have more than three common variants, while for others more than one example would be to much), but on the other hand, a fixed number is easier to enforce.
Regarding private builds: If there is no voting and no connection with the normal namespace, I dont see why we should forbid what users post and discuss on their user pages. As long as it is withhin the limits of GWW:USER, it is fine. --Xeeron 08:13, 24 February 2007 (EST)
On the subject of user builds (tier 2, private builds, whatever we decide to label them). Why should we force people off onto another site for that? We've taken away the major problem that most people had from guildwiki in that builds will not migrate to the main namespace. I appreciate that people have problems with the guildwiki build section but this is a fresh start with a different set of rules lets evaluate them for what they are, not on the bias of guildwiki. Lojiin 14:51, 24 February 2007 (EST)

(First post on new wiki) Everything Im going to say has been posted already, so if you dont want to read this, just skip it. I just wanted to post my opinion. I didnt read the entire thing, but I looked at the chunks of rules and major suggestions. I am a big fan of the builds section at Guild wiki and I think that builds are very important to Guild Wars therefore needs its own section. Agreed with GrammarNazi and others, I like the "Guides" idea better, it can be more controlled because the concepts are easier to test then, say, a build for farming The Mesmer "Whatchamacalits" in the "Zone of Terror Mission". Only core skills should be stated and only major variants posted. Each "Job" should have a page. Which means "Healer" has a page, "Tank" has a page and "Nuker" has a page. This then splits off into primary/secondary professions pages which have info on what the variant has to offer to make the build better. Basic synergies between skills or can be listed below, but other than that, the pages stays short and concise. In the discussion page, I think we should be able to talk about a subjective variant that an individual may have created. We can list, "Ive made a good variant to take down the monks faster" and then you click on the sig and it goes to the user page where you can post whatever you want. All disucssion on that particular variant stays there. To let people know about user page builds, post a template at the top saying, "This is a general guide to the build, please see userpages for more variants." I dont like the voting thing because it just makes people want to be voted on. People get very proud or very discouraged when they see votes on their builds. Agreed with Oblio, there is a lot of crazy game slang out there, and if you are new, or simply just never heard of it before, you want to know what it means. And this being an official wiki, I think needs to cover all of that. On the other hand, voting isnt so bad because you often learn a lot from your mistakes. I for one can speak true of this. My first builds, I thought, were, "invincible", "leet" "imsocoolgonnabefamous" etc, other peoples discussion hurt my ego, but I eventually did realise how the build was flawed. If you want to try something new, having an unfavoured section isnt so bad because it can show you [b]WHAT NOT TO DO[/b] without having to filter through all of the good builds. After all, good has no meaning if you cant compare it to bad. This however can be done within the userpager build discussions. It may be more work, but good things come to those who research and go through dozens of articles.--Hyprodimus Prime 20:06, 24 February 2007 (EST)

As written I like that the main namespace builds are for "well known/requested" builds, I like that user build stuff is limited to the user namespace. I don't like the "3 examples", just because it allows for people to be sloppy; 3 examples can be written as 1 example with variations listed. And I worry that there isn't an allowance for "builds which support a guide" (I know that is common sense, but it should be in there- I couldn't come up with good wording though :/ ). Other than that, I think the current version is pretty good. -- Oblio (talk) 18:29, 25 February 2007 (EST)

Having thought about this a bit more and after looking at the general awfulness of some of the comments seen in the Guild wiki build system today I think that it would be unwise to initially encourage any build commentary or feedback in this wiki in any form until it is clear that the builds in the information/wiki space can be controlled according to this policy without it being clouded by the possibility of bickering and nastiness going on in the user space. In future when the wiki is underway and it clear whether this policy works I think that the policy can be revisited and we can more fully assess whether a feedback scheme should be implemented.
My view is that we needn't specify anything to do with the user space in this policy and leave anything to do with the user space to the user space policy. I would like to remove the entire User space section and initially make it very clear that build discussions are not supported or encouraged in this wiki at this time. --Aspectacle 00:32, 5 March 2007 (EST)
Support. The builds policy should govern the builds space, not user space. -- sig 04:12, 5 March 2007 (EST)

Perfect Idea: Stick by it?

I find that the current policy for the builds section is perfect. It will stop the community from being ruined, as some might think. One section, with "vetted" builds, the very popular ones. . Then a User:Builds section containing users requests for thoughts on builds, instead of the usual flaming as witnessed from the original GuildWiki. Just thought I would put my thoughts out there. A+ Makes me feel safe from submitting my builds @_@-- BLacKGeNeRaL19px(talk|contribs) 17:32, 1 March 2007 (EST)

Off-topic but BlackGeneral, could you put in some spaces in your sig? It's a too-long unbroken string of text. It makes the history diff view and the edit text box way too wide causing avoidable horizontal scrolling. -- sig 22:49, 1 March 2007 (EST)
Done.— BlackGeneral 19px (talk|contribs) 05:39, 2 March 2007 (EST)

What about the builds listed on the official site?

I wont cry if someone ports them over here, but imho we dont need to copy stuff that is readily avaible on the official page. --Xeeron 06:03, 2 March 2007 (EST)
Disagree. There's no reason to not port over builds that are recognized by the official site. If it's worth mentioning on the official site, it's worth mentioning here. — Rapta (talk|contribs) 00:53, 4 March 2007 (EST)
It wouldn't matter if someone does port them here but wouldn't it be better to just put a link in the build section of GWW and have a link to that webpage?--Bane of Worlds 14:27, 4 March 2007 (EST)
The site doesn't always keep up with skill updates, so it could be worthwhile to post on here and allow for tweaks. ~ File:GeckoSprite.gif Pae 17:33, 4 March 2007 (EST)
It is worth nothing that the official site gets mocked quite often for some of the stuff that pops up in the PvP articles. They try and they do better than most, but stuff tends to get out of date and miss the mark. In addition, why bother porting over those builds. They are already up on the Guild Wars site, wouldn't it just be better to link directly to them and take no responsibility for them? -Warskull 14:23, 7 March 2007 (EST)
I think copying builds over because they are on is a bad idea. LordBiro 15:17, 7 March 2007 (EST)

Defining with a Vague Definition?

"Commonly used is defined by having any of the following attributes;

   * frequently requested by name in either PvE or PvP outposts.
   * frequently seen in observer mode GvG battles.
   * frequently discussed on user forums." 

Although there's really no way to really define common or frequently, how would this get away from someone posting what's really their own build and having sockpuppets/guildmates/friends backing them up when others say that it isn't frequently requested? If we go with the three favored more than unfavored like GuildWiki uses, someone just gets others to okay it, even if it isn't all that great and okays it. I suppose that it also involves a bit of overexaggeration, though, heh.

Also, I think that it's heavily determined by where each person plays. Someone who never steps foot in The Deep probably won't be seeing much of W/A Icy/Recall/Shove or something similar. That example is pretty obvious, but I'm sure that there are others that may be less so. ~ File:GeckoSprite.gif Pae 17:33, 4 March 2007 (EST)

You're thinking about the guild wiki scheme, IMO. There is no voting and "supporting" a build to be considered frequently used in the scheme detailed in the policy. I should be able to do any of the things listed and see the build being really wanted for a particular task for it to appear in this wiki. If someone has to convince and need sockpuppets and provide examples, it isn't a common build - it's *that* simple. Basically wiki will document builds that pretty much everyone who's played the game for a while has heard of already and it has been proven and well known for a certain purpose. --Aspectacle 03:11, 4 March 2007 (EST)


A week has passed since the last edit and the last discussions seemed to revolve around small issues which could be solved. Is this proposal ready to become policy? --Xeeron 11:06, 14 March 2007 (EDT)

Looks okay to me, although gome small fixes might be required later on, depending on how it works as is. -- Gem (gem / talk) 13:14, 14 March 2007 (EDT)
I doubt any consensus was reached. There are still a lot of supporters of no builds what-so-ever on the wiki (myself included.) -Warskull 15:11, 14 March 2007 (EDT)
The lack of agreed format is my primary concern - whether this proposal can become policy without it is questionable. And Warskull is correct - there will be no concensus on a build section, but I think this restrictive policy will be the closest you can get. --Aspectacle 17:46, 14 March 2007 (EDT)
Sometimes everyone needs to give up a little bit. This is restrictive, but still allowing. -- Gem (gem / talk) 18:17, 14 March 2007 (EDT)
Problem is that this policy doesn't address one of the major issues what will emerge. As the wiki grows a lot of people who don't have a clue will begin editing it and this is severely destructive to any builds section. People will insist they are right and regardless of what the policy says try to get their builds posted. You need people who know a good amount about given formats to maintain a build section and have veto power over the average user. In addition there is no consensus. If a policy like this gets enacted because it is "good enough, but there is no consensus" you will never get it changed. That is the same problem GuildWiki had. They enacted some poor policies for their build section and once the policies got entrenched they could never get them removed. The only sort of changes they can do are trivial organization changes because too many people fight things no matter what direction people try to take things. It would be better to state that there is no builds policy than to make one and not be able to get rid of it later. -Warskull 01:55, 15 March 2007 (EDT)
I'm in agreement that there will be people who don't bother reading policies and a lot of build articles ala GuildWiki will crop up. But I'm also willing to give this a try, since we do have people obviously putting in alot of effort in trying to get this accepted. I believe some of them are also willing to cut off the whole thing if it falls flat again. -- sig 02:59, 15 March 2007 (EDT)
Still it is really dangerous to implement something like this. While the people currently discussing it may be willing to give it the axe, once you have a large population would the users causing the system to fail be willing to give it the axe. It needs to be noted that the policy never had solid agreement to it. It may be best to give this policy a lifespan. For example after X months the policy needs to be reviewed and decisively voted on or the policy expires and the wiki defaults to having no build policy. Some safety mechanism to prevent it from getting locked in without ever having a strong agreement. -Warskull 03:26, 15 March 2007 (EDT)
What Warskull describes is the problem with all wikis - it is the power of the masses versus the knowledge and expertise of the few. In the system where "concensus" has to be reached that which has the most "votes" is going to win out in the end. This is something I have seen time and time again with crufty WoW articles in the wikipedia - there are so many fans there who think "Captain Placeholder" is interesting for the rest of us (and likely to be notable into the future?!?!) that AfDs fail to remove these articles time and time again. Builds will have the same sort of problems for similar sort of reasons.
I've often wished that there was a greater power, someone with knowledge and the power of veto to stop this sort of cruft - but it isn't the way of wikis, people come, people go, there is no true central authority governing the standard of content. I want to say "Warskull! You have the power! Kill build cruft, enforce the rules, keep the wiki sane!" but what if you leave - who replaces you, how are they selected, what right did I have to select you in the first place? Often in a wiki these people select themselves by their actions and their forcefulness rather than any particular qualification.
The idealist in me wants to make this policy work - wants builds to be in this wiki because I think that they do contribute something. This game is all about the skills and how you use them and builds are a big part of that. I acknowledge that any builds will probably need heavy moderation and there is a good chance this could crash and burn as so many posting above me have said and I can see the Guildwiki scheme is completely out of control. Yes perhaps if we go with this scheme a time limit is required. Criteria which say if the sort of build articles meet a particular standard of out of controlledness stops the whole build thing in it tracks. But what is that criteria (I can't think of anything but the rules already defined on this page) and then when the time comes how can you stop the masses of crappy build maniacs from calling foul and stopping it - you know that concensus thing...
um... yeh. :) I'll shut up now. I want the section, but can see the problems. I'm on the fence really I'm all talk and no solution. ;) --Aspectacle 04:48, 15 March 2007 (EDT)

Warskull is 100% correct, this policy should not be enacted without consensus. However I do hope that people will get around to this policy. Why? Because as long as we dont have a build policy, anything goes. If we are at the state we are now (no consensus on build policy) at the time the wiki is announced, we will have lots of builds inflowing and no way to delete them except consensus on each builds talk page (highly unlikely). --Xeeron 06:48, 15 March 2007 (EDT)

Yeah, we need to get a build policy before the wiki is officially announced. (or people find here en masse in a different manner) I support the current draft, but I realise the problems. We could make this a 6 month trial policy, after which the policy needs to be decided on again and the builds section is frozen untill a decision is made. (Discussion on the policy should probably be started after 5 months to avoid the problems of freezing the builds section) -- Gem (gem / talk) 13:45, 15 March 2007 (EDT)

I think it's important to note that, since we're a wiki, we're essentially open by default. That is, we don't need to specifically give permission to post an article, but we do need to specifically revoke permission to remove one. This is the opposite of most fansites, where every piece of submitted content requires approval. On the GuildWiki, it was fairly easy to revoke this permission, as any sysop had the authority to do so at any time. Thus, we generally didn't write policy, and when we did, it was solely based upon what prominent sysops were already doing.

Here on the official wiki, we do not have this authority. This means that we must have a policy in place before we're announced. It also means we have considerable flexibility later to tighten or loosen the policy as we see fit -- on the GuildWiki, we don't really have this, as any sysop could simply choose not to enforce policy, or he could choose to enforce a policy of his own design.

The reason I'm writing this is because everybody here is likely from one of two environments: either a heavily moderated, forum-based fansite or the GuildWiki. Both of these environments are significantly different than the Official Wiki, and we need to keep that in mind.

I'd like to express my support for the policy as written, with the condition that the formatting link is made blue before the wiki is announced.

Tanaric 16:28, 15 March 2007 (EDT)

Builds formatting guideline

In reply to Tanaric above, we should hurry the adoption of a formatting guideline for builds. This page is the place where that guideline should be (according to the policy article). Personally, I like the way that Starburster is formatted at the moment, including the example subpage. Those build pages should really be more about the build than posting the build explicitly. The formatting guideline should reflect and promote that. ~ dragon legacy 04:12, 22 March 2007 (EDT)

Could you perhaps talk about it on the talk page of the formatting page? Guild Wars Wiki talk:Formatting/Builds. I wrote a bit there the other day which didn't get much attention. :( Incidentally I agree with that sort of formatting and have done another few examples (which may or may not be crap) which are linked off that page. --Aspectacle 04:20, 22 March 2007 (EDT)
First of all, the attention is needed here. Secondly, I'm of the opinion that your drafts are still too much focused on the actual skill set and not so much about the hows and whys of the build itself. They seem to contain just too many bullets. ~ dragon legacy 17:18, 22 March 2007 (EDT)
I would like the build articles to concentrate on the guide, not just the specific skills and attributes and their variants. The guide should make it possible for users to form their own ideas on the build. Skill bars should still be present, but I would like a smaller version of the GuildWiki skill bar to be used, including the skill icon and name, but being a lot smaller so that it doesn't steal the attention. Attributes should not be listed in a big box, and possibly not at all if they aren't really needed to be set uo in a certain way for the build idea to work. -- Gem (gem / talk) 17:47, 22 March 2007 (EDT)
So starburster is fine but it is a very simple build basically relying on one skill - to describe it isn't really complex enough to make a good formatting guide with. It is easy to write sentences rather than bullet points because there is little to capture about the build. Minion masters, however, have more skills, more variants which you want to capture in the one space so I suggest that moving forward we should engineer a formatting policy using it as an example, and applying any changes back to the simpler build to see whether we've over-engineered a solution.
As to too many bullet points - Sure there are a lot of bullet points on the page User:Aspectacle/Minion Master, but do you agree that it captures the important information about a Minion Master, is there anything important missing which would need to go into a build/guide? Should sections be moved around to emphasise 'how' over the skills used, should some sections be removed or merged? How much value do sentences add to a list of advantages, disadvantages and counters - because in this case (perhaps with a little fluffing out on each point the page was only meant to be a rough draft) I like the bullet points it makes it clear what each point is. I'm also concerned that with sentences and paragraphs you might end up with something like the Gwiki minion master guide ramble which tells you absolutely everything about minions masters but doesn't really tell you what makes a particularly good build or really allow you to make informed decisions by narrowing the field a bit?
For builds such as starburster - no longer commonly used as described in the policy - we need to come up with a format or tag for the page to make it clear the build is no longer frequently used. --Aspectacle 18:34, 22 March 2007 (EDT)
I would like the guide to be first and the example skill bar + attribs at the bottom. The guide should be the main point. -- Gem (gem / talk) 19:11, 22 March 2007 (EDT)
To say what makes a specific MM build a good build, that's exactly what we don't want to. Our foremost objective is to document and that is saying what's commonly used and what's fact. The MM guide on GWG is actually a good example of a guide and all that "rambling" serves exactly the purpose of making clear, what a MM is and how it is played. ~ dragon legacy 05:37, 23 March 2007 (EDT)
Yes, the MM and trapping guides in GWiki are perfect examples. -- Gem (gem / talk) 05:51, 23 March 2007 (EDT)

Stopgap Measures

Since it was claimed the wiki would be officially announced earlier today, yet there is no solid build policy a stop gap measure should be put in place. I would advise implementing a temporary policy of no builds with a lifespan of about 2 weeks after the wiki is officially announced, while the details of build formatting and the build policy are decided upon. The worst is going to come right after it is announced. Deletion of build articles will stop a rapid influx of crap. Those who have more than a passing interest will stick around. Then once the temporary no builds order expires implement whatever formatting and guidelines was decided on (looks like guides, not builds.) However, I highly advise building in an abort button to whatever build policy is implemented that allows build posting. You don't want to end up like GuildWiki and have a build section that makes the wiki users look incompetent or dumb firmly lodged in place for an extended period of time. This should give admins a little more time to figure out their formatting rules too. No sense having people post a bunch of articles that don't come anything near the guidelines for a decent article. -Warskull 20:08, 23 March 2007 (EDT)

Guild Wars Wiki:Article retention already disallows all Build and Guild articles until their respective policies are finished. --Dirigible 20:20, 23 March 2007 (EDT)
Which is good. — Rapta (talk|contribs) 21:11, 23 March 2007 (EDT)

All Builds or No builds

I think in all terms of fairness and in the best needs as not to alienate anyone the builds section either shouldn't exist, or be the chaotic yet fun mess of guildwiki. Why? If we only allowed build that the top-100 rune or that are flavors of the month that would be elitist. We CANNOT under any situation allow the official wiki for Guild Wars to be elitist like that, or that would be extension make Guild Wars itself elitist. It must be all or nothing. We either let any Joe make a build or no one make a build. I am personally in favor of listing no builds, instead possibly making a separate GW Buildwiki or something.--Mortazo 17:42, 28 March 2007 (EDT) ... I'm confused as to why thats a bad thing. Unless we are arrogant... are we? Would that be arrogant??? And if in any case it would make the section discriminant, and not fair, if we had all of the top builds that are either "vetted" or "approved" and are actually prime builds why not have them be part of this offiwiki? — BlackGeneral 19px (talk|contribs) 18:04, 28 March 2007 (EDT)
(Edit conflict) I disagree with Mortazo. First, I don't see anything "fun" in the current build system of GuildWiki. Second, as mentioned often in this talk page, the purpose of the builds is to document common definitions used in the game, so a player that often notices messages of "GLF Minion Masters" in game may come here and find what those people are talking about - I don't believe the Wiki's purpose is to display new builds, no matter how good the user who created them think they are, neither do I think it should be. Without new builds, the idea of elitism does not exist - if anything, it would be more elitist to not allow newer players to know what all those expressions such as "nuker", "Minion Master" and etc mean. Erasculio 18:08, 28 March 2007 (EDT)
Any term coined in-game such as "Nuker" or "Minion Master" can be explained without needing a builds section. — Rapta (talk|contribs) 18:17, 28 March 2007 (EDT)
The explanation is what I would expect for a build section - like mentioned (somewhere) above, the idea would be more to have something like this than this - I'm against having the later on the wiki (just a skillbar with a few notes on how to use them), but I would like the former here, on the builds section, as the only kind of build available. Erasculio 18:25, 28 March 2007 (EDT)
Or simply a statement like "a character which employs the use of Necromancer Minion-Animation skills". =P — Rapta (talk|contribs) 20:16, 28 March 2007 (EDT)
Let me re-state my statement. Or remake it in other words. By having vetted or approved I mean builds that have been around long enough to be used by everyone. As stated many times, MM and such would fit into that catagory. Nothing like new builds such as BoA should be put into the catagory because it isn't something new players would run into. I agree with you on that. My statement was worded wrong. — BlackGeneral 19px (talk|contribs) 18:15, 28 March 2007 (EDT)
Heh, sorry, It's my fault since I'm a Wiki n00b and I don't know the convention for that kind of thing. My "I disagree" message was aimed at Mortazo, what happened is that I wrote it while you were writting, so I got a Edit conflict. I didn't want to make a new indent since it was just following the same discussion, so I kept it below your reply hoping the (Edit conflict) note would be enough to make people realize what happened (it wasn't, but then again I should have added a new indent). I agree with you, hopefully it's more clear now : ) Erasculio 18:25, 28 March 2007 (EDT)
Where that term started from was when a bunch of experienced PvP'ers ventured over to GWiki to vote unfavored on extremely poor builds. The build writers' decided that this was "elitist", and thus, that complaint was born. It is basically an excuse made by poor build writers there to get their build promoted into such a status. A consequence of the flawed vetting system, no less. — Rapta (talk|contribs) 20:19, 28 March 2007 (EDT)

@Mortazo: Chaotic yet fun mess?? How many talk pages there how you gone through? I can't believe you call all those personal attacks and insults being thrown around "fun". The wiki is not a builds database, yet those in favor of a builds section believe that builds are an important part of the game. I'm not sure why you think some quality control on what builds get posted is elitist. The idea is to document the general themes and usage of popular and recognisable builds that are known to be successful. If you think that's elitist, then fine, we're elitist. I'd rather the wiki be called elitist and have builds known to be good than have thousands upon thousands of mediocre and downright poor builds. -- sig 21:11, 28 March 2007 (EDT)

I completely and whole-heartedly agree with your statement aberant, and I back it up by saying.. well, thats exactly what I think about it. — BlackGeneral 19px (talk|contribs) 01:59, 29 March 2007 (EDT)

Have to say that I actually find builds useful - even some of the "bad" builds works well in certain areas of the game - let's face it Guild Wars was designed around variety - and the fact that everything has a counter. I would love to see just a directory linking to other 'reputable' sources for builds. Let the decision whether it's a good build or a bad build fall to another source for now - and get the rest of the wiki up to scratch first. 20:37, 30 March 2007 (EDT)Fun

Heh. Well then,, you should probably go read GuildWiki's build section =P Really, I'm still supporting the idea of guides rather than builds and having a group of people in charge of choosing what builds are wiki-worthy. Personally? I actually disagree about the BoA 'sin, since it's still rather prevalent in PvP (Shadow Prison, anyone? I'm still thankful for that nerf), and was based on a rather good idea (casting a hex, and using it to spam offhands+duals, rather than having to waste a slot/energy on lead attacks). While I love the idea of restricting the builds we write guides about, and especially the idea of guides, not builds, we need to have some process in place for choosing what builds are worthy enough to merit their own articles, and I think we're all agreed that community vetting is not a valid option here =P Of course, if we did have a group of people like that, some would have to be PvPers, and some would have to be PvEers. As usual, just my 2 gil - I just think that, while we've got a fairly good theory about how we want to do this, we haven't really worked out any specifics on implementation as of yet. MisterPepe talk 22:36, 30 March 2007 (EDT)
I was using BoA as an example lol ^^ It is one of those FotM builds, so I guess it cold be put in. — BlackGeneral 19px (talk|contribs) 01:11, 31 March 2007 (EDT)
By that argument why not just publish anything that anyone wants so that no one feels that their contribution is not useful???? Being discriminatory about only publishing high quality articles is elitist isn't it? LordBiro 05:30, 31 March 2007 (EDT)
As was said before, elitist is not a bad thing (IMO), though people often use it like a swear word. There is such a thing as a horrible build - even if you think it rocks, a necromancer using an axe or a warrior trying to use Conjure Nightmare are not only less than helpful, they're probably even harmful to new players who are trying to learn how to play a role. I'm still supporting general guides showing various ways of setting up each build, benefits, drawbacks, and a full description of setting it up and playing each role, and only on builds that can actually qualify as, well, good. Is that elitist? Yes. Is that a bad thing? I really don't think so. BTW, LordBiro - didn't you agree with Skuld on limiting the builds previously in this discussion? =P MisterPepe talk 16:26, 31 March 2007 (EDT)
MisterPepe, I think LordBiro was agreeing with you - that elitism is not a bad thing, such as when we only accept a high quality article - there is a judgment there that is done for the betterment of the Wiki, no matter if it could be considered elitist by some. Likewise with builds - people could maybe see it as elitist that not all builds are allowed here, but that limitation (just as all the other self-imposed limitations here) is for the good of the Wiki. I still have the same opinion I mentioned above - keep the "Builds" only for those things a player could see asked for (or talked about) in game (such as "Minion Master", "BoA Assassin" and whatever else we may find by watching the All Chat in game), preferably with a description of how the build works and without an example skill bar (again, the link above to the GWiki Minion Master guide is the best example of what I think the builds here should be like). Erasculio 23:24, 31 March 2007 (EDT)
MisterPepe, I said that "Being discriminatory about only publishing high quality articles is elitist isn't it?", nowhere did I say that I think that elitism is bad, or that being discriminatory is bad. You seem to have presumed that by yourself :P LordBiro 07:31, 1 April 2007 (EDT)
Oops. Sorry, LordBiro, I apparently fail @ reading T_T Mea maxima culpa. Anyway, any chance that we can start to shift this conversation over to logistics and implemetation? It seems that we have something that's pretty close to a consensus regarding the core ideas "Guides, not builds" and "Limit the builds we write guides on." If we agree on those concepts, then all we really need to do is figure out how we're going to do it - this mainly involves formatting and a system for choosing the particular builds. As far as formatting, I've got nothing =P See my user page if you don't know what I mean... I'm really, really bad at formatting ideas. For the other part, I really think the idea from earlier, the one of a group that would decide these things, would make a lot of sense, though that's mainly because it's the only way I can think of actually being possible to implement that gets rid of the vetting procedure. If anyone has a better idea, please, spit it out =P MisterPepe talk 18:09, 1 April 2007 (EDT)


Despite much discussion, there is still not a fully acceptance of this policy. Soon we will likely be flooded by contributors thinking they can copy the GWiki Build Section, and so I think it's worth trying to bring this discussion back. Is there anyone against the policy as seen here that would like to speak in favor of some other idea, or just point the flaws in this one? I would like to accept a policy (hopefully this one) and begin worrying about the logistic aspects. Erasculio 19:17, 4 April 2007 (EDT)

See Guild Wars Wiki:Article retention#Builds. We aren't in a hurry.
I would suggest waiting a bit to see how the build discussions in the GWiki go. We might be able to use it to our advantage. I wouldn't be opposed to a exactly same or lightly modified version of what ever is decided on there. That would atleast make it easy for people to adapt. -- Gem (gem / talk) 19:21, 4 April 2007 (EDT)
I see no reason whatsoever to wait for GuildWiki. Different wiki, different policy. It will take months to first get a policy over there, then to see how it pans out. Let this community define its own policies. --- Barek (talkcontribs) - 12:22, 6 April 2007 (EDT)
Gem has a point that we could use some of the points there for this wiki (for example, I'm very fond of the NOB policy there and the "Guides, not builds" - together, I think those two are more or less what has been said above anyway), but I would rather not wait for the GuildWiki to set its own policy - not only because there isn't much point in waiting, but rather because I'm afraid part of the users there who won't be satisfied with the result would flow here and try to make the policy to be a copy of the old GWiki's one. The problem, IMO, is that many of the members here are members there, and the mood on GWiki about the build discussion is kinda heavy right now (as interesting as it is from someone outside, who agrees with the incoming change there), so asking the same people to have a similar discussion here, at the same time of the one there, would be asking too much, I think : D. Erasculio 13:16, 6 April 2007 (EDT)
The reasons why I would like to wait are:
  • GWiki can work as a nice testing ground so that we don't mess things up here.
  • Due to most active discussors in GWiki would also be the discussors here, the policy would end up pretty much the same and people would just get even more frustrated than they are with one discussion.
  • This wiki has more important areas to improve than the build section. We are still lacking a lot of really important content. Using massive amounts of time to discuss a policy and start the builds section would take time from the main article name space. -- Gem (gem / talk) 15:59, 6 April 2007 (EDT)
Why wait though? As you said "GWiki can work as a nice testing ground so that we don't mess things up here." You need to get over the fact that this is not GWiki. We need to be two diffrent wiki's, as they are in reality. It is useless and futile to depend on waiting for GWiki to make up its mind. We need to stop letting people who are afraid of the GWiki Build fiasco make all the decisions. This is a community, and just because we can't make a precise deal, doesn't mean we should limit our wiki. We need to come up with a solution NOW, and give players a reason to come to GWW, instead of going to GuildWiki --DяấĢő 23:12, 6 April 2007 (EDT)
See my last two points on the above comment on my thoughts. -- Gem (gem / talk) 06:42, 7 April 2007 (EDT)
Gem, are you stalling for time, in all seriousness? Are you that afraid of what might happen? It seems to me, like you want to see if it will blow up in the face of GWiki, so then we have a reason to not have builds. I really don't see why the discussion at wiki is of any importance at all, we as a wiki, need to ignore GWiki and work on ourselves. And since it is a wiki, why are you so afraid of mistakes? They are correctable. - DяấĢő 12:34, 7 April 2007 (EDT)
That's just my opinnion. If people disagree with me, that's ok. -- Gem (gem / talk) 13:48, 7 April 2007 (EDT)
Instead of accusing Gem of being scared of having to clean things up (yes, correctable, but only a small group of users can "correct" it), you can help move things along by seeing if there's anything else that's need to be added to this policy proposal. To me, it seems very short. Is there a Build namespace? Who has final say as to what's considered "common build"? Are we going to have a naming convention? Do we limit the names of builds to roles? How much of a difference before two builds are not considered variations of each other? Which variation takes precedence? It's also not clear if we're going for a role-centric build article, or a skillset-centric build article. It also sorely needs a builds formatting guideline. -- sig 23:15, 7 April 2007 (EDT)
I don't see a need to decide this "NOW". Neither do I think the Builds section is going to be something that would make people use this wiki instead of GWiki (in fact I don't want it to be - the policy that appears to be the most popular there is the one I think we're going to use here, so there isn't really going to be that much of a difference). If people who would like to discuss it here (such as Gem) are too stressed over the build discussion on GWiki (which is very stressful at the moment) and would rather wait a bit longer, I don't really have any major problem with it (my only concern is if, after the wipe, people come to flood here demanding to post their builds, but we'll have to see what happens then).
To answer Aberrant's questions with my opinions: I think this should be our basis for the formatting. As in, having a guide for each main role ("Tank", "MM", "Nuker", etc), with an explanation of the mechanics behind it (for example, I have began the Tank article, and I plan to add there a description of how aggro and aggro bridges work), a list of skills related to it, and a strategy sections with hints on how to do it. No builds - no skill bar, even: if people understand the role, they should be able to make their own builds, suited to their own characteristics. The PvE versions may be defined by pure consensus - I think we would all agree that MM is a role, while "Fragility + Phantom Pain Mesmer" isn't, for example. PvP wise it would be harder - we would both need people who bother going to places such as HA and TA to see what builds are asked for there (which relates to what are the current roles there) and people who know the current GvG metagame enough to understand the logic behind the "cookie cutter" GvG builds and be able to convert them from builds to roles. Erasculio 23:44, 7 April 2007 (EDT)
Just a quick note: Perhaps this should be done like the Guild Wiki main page. In order to change the build section you have to make a proposal. Perhaps we could introduce another type of administrator into the administration draft. There only ability would be to create a new build page (e.g. a page that's a guide to SV Necs). Creating a page in the builds category would be locked to other users. on their user page, they maybe would have something other than a talk button. Other than that Regulatory idea, I think the current policy is good. The only problem would be that we would have to come up with a whole new type of administrator for the administrator policy. Jibjabman 19:33, 9 April 2007 (EDT)
This sort of an idea has been suggested before. It always gets rejected because it goes against what a wiki is. If you think restricting who has the right to create builds pages is necessary to make this work, then it means you think that builds doesn't work in a wiki. Might as well just start a build forum and only allow moderators to create new threads. -- sig 22:55, 9 April 2007 (EDT)
If this is what it takes I think it should be done. We cannot ignore that builds exist. If this wiki is ever to go in-game, then something will have to be done about common builds. not specific, mind you, but the general idea behind a build. And it has to be regulated, else we'd end up with a failed expirement, like Guildwiki. people can post specific builds in their user pages if they want, however, the builds section needs to be regulated. We must not forget that this is not only intended to be a wiki, but also an in-game resource. If it's ever going to be of any use to new players, then it needs to have some stuff on what new players want to know about. I feel this is a viable solution, and that it addresses all of the problems. no, it's not what you wold normally expect on the wiki, but you must realize this admin would only make the page, regular people would write the actual info. it would not destroy the community sense of the section. This admin would be sort of like a zoning permit. he allows the building to be built, but does not do the building. Jibjabman 10:41, 10 April 2007 (EDT)
Like I said elsewhere, I don't think that the wiki software offers us the possibility of such a user class. Also, I'm definitely against a nominated group of people who regulate the builds section as are many other people. It is highly unwikilike. -- Gem (gem / talk) 13:05, 10 April 2007 (EDT)
I also don't see the need for this. A system in which no original builds are posted and in which guides are prefered to builds will have the content that new players seek - instead of coming here looking for a "Tank" build and finding dozens of variants without knowing which one is good and which one is bad, a player would find the "Tank" guide teaching how tanking works and giving some ideas of how it's done. There is no need for an "enforcer" to such concept - we know that a "Nuker" is something that needs a guide, as it's asked often, but a "Dervish/Monk with Vow of Silence" is not. Erasculio 13:35, 10 April 2007 (EDT)
Perhaps I was being unclear. This person was intended to be a sort of modified Sysop. he was meant to keep the builds section under control. Quite obviously this does not sit well with the community, and so should not be implemented. The admin, however, was not the point. the more important point was the proposal. A bureaucrat could simply decide whether or not it belonged in the builds section. The point of this would be to keep the section organized by not allowing people to put whatever they want in it. The bureaucrat or or other admin would simply decide wether it was general enough. Without the specialized admin this would not take the community away from the builds section. It would operate by someone submitting a proposal, and then, like the guildwiki homepage, the builds section would be changed to allow this new generalized build definition to be edited. All the bureaucrat would do would be place a link in the index or something along those lines. I also strongly believe that these should be modeled after the minion master article. The point was the proposal, not the admin, so I would ask you all to reconsider.
I think it's clear. You might have misunderstood our meaning about "not in the nature of a wiki". We do not believe that it is fine to have a select person or selected persons to be "in charge" of approving links to other pages. Nobody should be "in charge" of any particular page. -- sig 23:25, 11 April 2007 (EDT)

(RI) Aren't you, by definition, doing that with the sysops? Or, do you assume that no one will ever try to post a build that is not "commonly used?" While I agree, in concept, some of them will either have to be cleaned out or never approved in the first place. Which way would you rather do it? Of course, unless it's approval to start out with, we'll end up with massive arguments about "My build is commonly used!!!!1!eleven! My wholez guilkd farms with it daily!" While (hopefully) and exaggeration, I think you know what I'm talking about. Heh. I also forsee people grabbing a bunch of friends/sockpuppet accounts and spamming the talk page with "I use this build, everyone does, so it's commonly used!" Of course, I'm somewhat paranoid. Really, before this goes any farther, this is what we need to figure out - how we differentiate between commonly used and general junk, and how we enforce that.
I also think that the definition of "commonly used" is rather vague at the moment, though I have no idea of how to strengthen it =P I'm especially worried about the "frequently discussed on user forums" concept - I can think of several build threads that stretched for 10+ pages simply because the author was ranting at everyone who said anything against his very, very bad build. With the A/E green farmer build that's currently posted, it's a build based on the use of two skills: Shadow Form and Sliver Armor. Does that qualify as "commonly used?" Also, for bonus points, it was created in the non-existant Build: namespace. While it (for the most part) complies to the still-under-construction formatting guide, I personally don't think it deserves to have wiki mention. MisterPepe talk 11:45, 12 April 2007 (EDT)

IMO: The A/E green farmer build would be removed, and replaced with a "Shadow Form Farmer Guide", that would belong in the same category as the "55 HP Farmer Guide", and so on. There are a few farming gimminicks that are used often to farm in many different variations (such as all the different kinds of 55 farming), and so I think having the main idea, leaving the readers to fill the blanks, is enough. Keeping the subjects broad enough (guides, not builds) ought to prevent a bit of the "But me and my 100 imaginary friends use this build, so it's common!" aguments from happening (or at least I hope so >.>). For the other cases ("Hey, everyone uses a Melandru Farmer, I have a long guide about it right here!"), I think it's something the community would have to discuss - but discuss, not vote. The point would not be if people think the build is good or not, but rather if it is common enough to be considered something to make a guide about. If the result of the discussion (again, discussion, not voting) is that no, it isn't, then we could add a delete tag to the page. Erasculio 12:23, 12 April 2007 (EDT)

2 cents worth from the perspective of someone who really needs to use a Wiki like this

Right so I figure I should give my perspective, as someone who has played GW on and off for some time but never really got into PvP properly (other than Random Arenas) and never put that much time into PvE-ing either.

I really, really don't want to read an article about "Bob's awesome touch ranger which is much better than all those other sucky touch rangers". I want to read an article about touch rangers in general which tells me what exactly they are, highlights common skills used, explains some possible variations and how they affect skill or secondary profession choices (irrelevant in the case of TRs), common mistakes in building/playing them, whether they are generally accepted as good or bad things to run in PvE or PvP or if they have specific narrow applications (ie alliance battles or farming particular areas) and the template strings for a couple of typical or representative - not experimental - builds so I can easily try them out and see for myself. I don't care if the builds shown are not the "latest technology", I just want to gain an understanding of what the concept of a touch ranger actually means.

If I decide that I want more detail about particular builds or want some ideas I'll go to a forum and read the discussion, but that's not what a Wiki is for. I mean, I don't actually know what a touch ranger is really. I just have a general sense that it's a ranger who uses blood magic life-stealing skills. I'm sure there are really important aspects of touch rangers which I am completely unaware of, because there isn't anywhere I can just go for a general description with a couple of examples of typical or common builds. But adding more than a couple of builds, or adding contentious or experimental builds to a touch ranger article adds nothing. In fact it actually takes something away from the article - it makes it overly complicated and possibly confusing to new or inexperienced players like myself. --The preceding unsigned comment was added by User:Darkfoot .

Written just for you: Touch ranger. --Xeeron 11:13, 11 April 2007 (EDT)
Xeeron for the win! :)
What you're saying makes sense to me though, Darkfoot. I'd be fine with having guides of the kind you're describing and of the style that Xeeron just whipped up, they seem very beneficial to me. --Dirigible 11:43, 11 April 2007 (EDT)
Thank you, Darkfoot, that's a really good point :) And good work Xeeron on the quick response. I really do like the idea of guides. LordBiro 12:22, 11 April 2007 (EDT)
I think that's the direction the discussion here is gearing into. I would only like to remove the example in Xeeron's guide - I would rather list some skills and say why and how they are used, instead of putting them together. Then again I may be being overzealous. Erasculio 12:53, 11 April 2007 (EDT)
As someone else who also really needs to use a wiki like this I'd just like to add one more thing I hope is included. Along with saying something works for PvE or PvP I'd hope it also includes whether the build is useful for Heroes. This is something that is often ignored or forgotten on other sites. A simple, "This build has been found to be less effective for heroes because under the current AI, heroes use the skills in the improper order," would be so helpful. If it is unknown how well heroes actually fare under a particular build, just state that so that others will recognize that's an area they can contribute.LoverOfJoy 10:53, 14 April 2007 (EDT)


Why just commonly? If it is common then people have no way of getting their possibly new builds out there. That means we will only be sticking to the same Metagame all the time and people who don't know alot of builds will be screwed.--Eloc 05:28, 11 April 2007 (EDT)

They can always use forums or gwshack. - BeXoR 05:30, 11 April 2007 (EDT)
The reasoning is the same as in GWiki NOB suggestion. The wiki documents the game, it doesn't create the game. Forums are better suited for build and metagame forming, the wiki for documenting. -- Gem (gem / talk) 06:04, 11 April 2007 (EDT)

edit conflict :(

Wiki's shouldn't cater to build authors, they should cater to readers. While there might be some value in providing original builds there is undoubtedly more value in providing good builds, and only a very small subset of original builds are good. The most sensible course of action, then, is to only allow common/popular builds. If an original build is good then people will use it and it will become common/popular. LordBiro 06:06, 11 April 2007 (EDT)
For the records, I agree. I really wouldn't like to have original builds here. Erasculio 12:54, 11 April 2007 (EDT)
I highly doubt that GuildWiki is the current major source of new builds that became popularly/commonly used. -- sig 23:30, 11 April 2007 (EDT)

Thanks for that TR article, that explained several things I didn't know :-)

I think I'd like to add to my previous (unsigned - my apologies!) comment that I think builds are useful in "guide" articles, because they help someone (like me) who is new to a particular strategy to start developing it from a decent starting point, rather than having to go lose 5 random arena battles (and probably get called all sort of nasty things by teammates) before realising that a TR needs an energy management elite to work properly. In that sense, any builds posted in these guide articles should merely serve as a good starting point, to be adapted by each individual player with their play style/skill preferences in mind, rather than any sort of definitive "best build". The example builds should be as close as possible to a "vanilla" build, if that makes sense. Darkfoot 00:39, 12 April 2007 (EDT)

I had not thought about it before, but when I wrote the TR article, I used the (other) Guildwiki article as an example. To begin with, that was simply born out of lazyness - I didnt want to write something I knew existed - but I am starting to like the idea of linking to off-site example builds (if there is one). We can link to those builds we need in guildwiki and dont have to host them here, meaning we can cherry pick the good ones and ignore the crappy builds.
Of course if they are all deleted and not restored there, the idea goes down the drain. --Xeeron 11:22, 12 April 2007 (EDT)
Linking to actual builds that exemplify what the guide is talking about is a good idea. That way we can link to forum posts as well. Several example links of course, so as not to imply that we should try to link to every such build ever posted on forums. -- sig 00:04, 13 April 2007 (EDT)
Linking to forums is simultaneously (a bit of) prove towards the build being common and saves us the trouble of making it here. But that goes only for forums which have a useful builds format (e.g. gwguru with their skill pop-ups). Just a list of skills without descriptions doesnt cut it for me. In that case I would redo the example build here. --Xeeron 05:17, 13 April 2007 (EDT)
Personally I don't agree with offsite linking to GuildWiki. This is a bit of a difficult issue, because I obviously love GuildWiki, but I think that if we link to a build on GuildWiki from here it might be confusing to the reader, since much of the content on GuildWiki is similar to this one. LordBiro 05:39, 13 April 2007 (EDT)
As long as guildwiki has the high quality it has now (arguably as high or higher than guildwarswiki atm), I dont see a problem. Some casual viewers might not notice that they were linked to another wiki, but for them, it should not matter anyway. The links on an actual example build are in 99% of the cases skill or attribute articles, which should be identical in all but presentation. --Xeeron 08:25, 13 April 2007 (EDT)
I'm for a build section on this Wiki if in can be done properly and maintained without the rise of vandilism. I agree that people shouldn't be able to easily access the build section and just slap up anything that might come to mind as that would allow this to become a sloppy mess like the other wiki. If a build could be submitted and reviewed and perhaps voted on to be permanently added by the community then what would be the harm? Maybe that wouldn't be the correct method or system but something that we could all agree upon that would be fair and proper would be in the communities best interest. This wiki will become the definitive source for Guild Wars I and Guild Wars II and will be linked from inside the game to be easily accesible. I mean honestly, apart from some sore ego's here and there and over zealous opinions about certain builds what is the real harm? It will be easily accesible for new comers who need help and ideas on good synergetic builds to run. If they happen to be so called "cookie cutter's", so what? The intention is to help people to be succesfull in the game to a degree, and to help them to have FUN. --Hysteria 10:02 14 April 2007 (EDT)
I don't think so. I don't believe user posted builds help. A new player, the one that needs to know what the builds are, does not understand the game well enough to realize which build is good and which build is bad. And there is no viable system to measure whether a build is good or not - just to say "your build is bad" is going to bring more problems than it's worth. I would rather keep this wiki for what it is - documenting the game while helping new players - than as a BuildWiki. Erasculio 19:17, 16 April 2007 (EDT)

Player-made and untested builds

What if, instead of having people be able to create there own builds and put them on the wiki (which everyone is arguing whether we should or shouldn't.) Instead, we could have a section for user made builds, with a tested/untested section similar to the Unofficial Wiki. But maybe on each page we could have a disclaimer saying that "These are player made builds..."etc... Then we could have a section for guides, and succesful builds that are "high quality"; more like articles than builds. And a whole seperate section for builds. Morrock 15:56, 15 April 2007 (EDT)

Any form of vetting is doomed to failure in a wiki environment. It's a large part of why the section is being reset on the unofficial wiki - voting for tested/unfavored was the root cause of the majority of the problems perceived to exist in the section over there. --- Barek (talkcontribs) - 15:58, 15 April 2007 (EDT)

Another idea

I don't know if I'm too late into this, and I also have a very short attention span (read: I didn't read any of the above). However, I do have an idea, and if it is good enough, people can run with it. If it is not, shoot it down massively please.

Idea: instead of a build pages...have skill synergy pages. On guildwiki, many builds were unfavoured because of the skill choice: they just don't work well together, or a player not familiar with better skills uses inferior skills. We instead have maybe small skill articles (or something) that says which skills are good together, and why.

No more than 3 skills per article. For example: Death Blossom and Moebius Strike. Doing this has a few ups:

  1. I assume people will not be as attached to these skill synergies than an entire build.
  2. Easier to manage. When something gets a nerf, or buff, the synergies will be directly related to said nerfs and buffs.
  3. No need to vote.

We could maybe even just add a synergy section to each skill article. It's already done in the notes...but not to the extent that I'm thinking.

The point is to have something simple, keep it simple, to be easily managed.

That's the general idea. There might be flaws, but please think about it. Might just work. --- δ(x) 00:39, 16 April 2007 (EDT)

Not a bad idea, but if You had read the above you will see that therhe are some better things that we can do. I personanlly have a good idea on how to fix them all together but Im still making my example for it. Merlin talk Contr 18:40, 16 April 2007 (EDT)
I think this would probably be less valuable than a 'only famous builds' section (i.e. only really well-known ones like SF, Barrager etc.). I think most users can work out for themselves that Searing Flames and Glowing Gaze work well together, for example. What they might not be able to work out for themselves is what other skills (e.g. Liquid Flame), and more so the attribute levels, make the most effective combination. Please let's have Build:Minion Master and not Synergy:Server Artery then Gash then Final Thrust. Cynical 14:40, 23 April 2007 (EDT)
Less useful. Exactly how much more can you talk about skill synergies outside of a usage notes section? I'm shooting it down :P mainly because I find an explanation of why 8+ skills go together well much more useful than little notes regarding 3 synergistic skills. "Uh.. sure, they have synergy, so... what's a good build to use them with?" Synergies inspire builds. -- sig 23:59, 23 April 2007 (EDT) you'll humor me, just to continue the discussion, let the synergies inspire builds. This will mainly aid people with classes they are not familiar with. Granted, obvious synergies are have less of a contribution value. However, I'm thinking the main sell is probably from cross-class synergies, like Flurry and Choking Gas.
Again, might not be a new page, but something under usage notes, or new synergy section for each skill. It can't solve all problems, but I find that a good build usually has a good core of a few skills. (Yes, some builds like MM is a 8 skill build, but a whammo is just Frenzy+Mending+Healing Signet).
The main spirit of the idea: Keep it simple, remove voting process. This is just a possible proposal to satisfy. Regardless, this is not (yet?) a silver bullet, but a start in a different direction. Just throwing this idea out there(...and the wolves.) — δ(x) 01:19, 24 April 2007 (EDT)

Guides/Roles continuation

The above looked like they were both talking about similar things. I recently added an example on the page Guild Wars Wiki:Formatting/Builds where it lists Touch ranger where I just created and added Barrage ranger to the example list basing it off the Touch ranger page style. It reads as a guide mostly with an example of the build details at my userspace for now (that's why the link reads "Temporary"). I don't see why guides can't be made like these as it does cover the role/type and some skills and options with a build example detail link listed at the end. As it's one of the "historical" roles/types of rangers then it can easily be kept or modified as needed by all. The only thing that remains is the roles/types that are to have guides made for them. Good thing is that a "55" guide (for example) could be made covering multiple professions and the example links at the bottom could have one for each profession that may typically use that method.

I think this should work if it keeps going as it doesn't promote new builds in a build space but it should promote a guide and one to a few example builds per role/type. Unique, specific, or unpopular builds can then easily be kept on user pages as previously mentioned. Lastly, the types/roles guides will need to be linked from somewhere though. As not all would be profession specific they can't be placed on the profession pages so then would they be linked on the builds link or even have a guides link on the main page next to it? Of course this is assuming that all that will be made policy... --File:VallenIconwhitesmall.JPG Vallen Frostweaver 10:29, 25 April 2007 (EDT)

Builds as guides is fine. Can I ask what's stopping this from being made policy? Can't seem to see it from the more recent discussions. If nobody voices out, let's "policy-ise" this thing. -- sig 21:05, 25 April 2007 (EDT)
I agree. --File:VallenIconwhitesmall.JPG Vallen Frostweaver 21:36, 25 April 2007 (EDT)
Guys, note that the current policy is not recommending "guides, not builds". The current policy is suggesting builds, plain and simple, and so is Formatting/Builds. Apparently the final decision was that the difference between a guide and a build is wordiness. Is touch ranger a guide or a build? How about starburster, shock warrior or even frenzybot? I see them all as actual builds, where {{skill bar}} has been replaced with an uglier formatting style with written out skills instead of using the fancy skillbar template. Once again, be aware that the current policy is allowing builds, not guides.
Which builds are retained and which aren't? The current proposal seems to be a variant of "No original builds", suggesting the term "commonly used", how is that measured? How do you figure out what's a commonly used build in RA? How about TA? Heck, even GvG and HA, do we get people to sit in obs and take note of what they see? "frequently discussed on user forums" is a very ambiguous description. User forums including fansites, guild forums, etc? On my guild forums we're always discussing the possibility of running an 7 A/Me with conjure phantasm and locusts fury, do we get to put that build here? And, of course, that "frequently seen/discussed/requested" is also very ambiguous, what exactly is frequently supposed to be? I log on, no one on obs is running a Shock Axe warrior, and I come post here "not a single team in obs mode is running this, it must be a crappy original build. LYNCH IT!" and it's gone? If it's supposed to be by consensus then I see nothing suggesting how that whole process is going to work in this page.
The policy proposal right now leaves much to be desired. It reads like a much less detailed and much less refined version of GuildWiki's NOB. --Dirigible 05:51, 26 April 2007 (EDT)
How is this less refined than NOB? Granted it doesnt need 2 pages to describe a simple concept, but is that a bad idea? Tell me where there is a way specified in NOB to find out whether the build should be retained. All it says (and repeats several times) is "If deemed popular and successful" which is less specific than our policy (frequently requested by name in either PvE or PvP outposts/frequently seen in observer mode GvG & Heroes' Ascent battles/frequently discussed on user forums).
NOB also has the criterion "successful" in it, which is a sure to lead to conflicts about what is successful, while we go for all common builds, with no discussion about "successfulness" only about the frequency of use. That way we stay much closer to objectiveness than NOB. About your example: Being discussed on one single guilds forum, without reports that it is actually run is definitely NOT "frequently discussed on user forums". So your 7 A/me build would be shot down right away. Please dont use examples in your arguements against this policy that are obviously disallowed by the policy. --Xeeron 06:15, 26 April 2007 (EDT)
Oh, come on, NOB has an entire subsection explaining that the "commonly used" qualifier is decided by discussion and how that process is going to work. While the current proposal here only repeats "it needs to be commonly used or frequently seen/discussed/requested", with not even a single hint of how exactly that "commonly" or "frequently" are supposed to be decided on.
And no, the 7 A/Me would not be shot down right away, not according to what's written down in the policy right now. As I said above, "frequently discussed on user forums" is very ambiguous. It makes no differentiation between a 5-man guild forum, the Guru forums or the QQ forums. Nor does it distinguish between the build needing to be discussed on one forum and multiple places. Even if it's multiple places, it makes no attempt to handle issues like a build discussed in the forums of guilds in the same alliance, or 5 friends each having his own forum and discussing the same build on each other's sites; would that make the build suddenly good to go for this wiki? Do not confuse what you think the policy means with what it's actually saying. Because right now the policy is saying very little.
And yes, 2 pages of details to fully explain these policies are a Good Thing, because you and I might lose interest in the wiki/GW tomorrow and leave, what's left behind here is what's written down on the policy, not how you or I interpret it. --Dirigible 06:54, 26 April 2007 (EDT)
I've reworded most parts of it and tried to take some of your points into consideration. Does it still have problems? -- sig 07:04, 26 April 2007 (EDT)
Looks better. :) I'm not going to say I support this policy since I simply do not agree with builds on the wiki, period, but I'm not going to get in the way of those that do want them, either. Here's an open question to everyone, though.
The formatting guideline right now says "Disallowed: Avoid providing a skill bar or attribute list in the build explanation; place them in an example build". The policy page says "Actual build examples, while allowed, are secondary and unnecessary to the explanations, and should only serve to illustrate the ideas that were explained". Take a look at these particular articles: Starburster, Touch ranger, Shock warrior, Frenzybot. All four of those builds are providing a skillbar and simply explaining the usage of those skills, are those pages acceptable or not? Are they the kind of article we're looking for? (Honest question, not a rhetorical one.) --Dirigible 07:42, 26 April 2007 (EDT)
Wow, I have rarely disagreed so completely about everything with someone like in this discussion with you here Dirigible. =)
For the sake of keeping the discussion on topic, let me reply just to the articles you mentioned here, I'll reply to the other stuff on your talk page later. I dont see a skill bar on any of those pages. There are skills mentioned (briefly); in all cases, most of the text is about the usage of the skill interaction. That is indeed what I want to see in build articles (and in guides as well). So to answer your question: Yes those are exactly the kind of article I am looking for. --Xeeron 07:51, 26 April 2007 (EDT)
I actually agree with Dirigible. I think we need the policy to be made as complete as possible, especially considering the context we are in right now (with GuildWiki about to remove their own builds). I would also like to make the policy more strict - I would remove the two later points to the definition of "commonly used" and keep just the first one, "Frequently requested by name in either PvE or PvP outposts", as that's the one easier to check - Dirigible's point about how hard it is to quantify any of the other two definitions is something I completely agree with. I would rather even remove the example builds from all guides, and I would rather have the Starbuster and Shock warrior guides reworded into "Point blank damage elementalists" and "Knock down warriors", listing (and explaining) the many different strategies for each role, including the ones that currently have a page on their own. I think it's important to make the difference from "builds" to "guides" more clear than it currently is. Erasculio 08:49, 26 April 2007 (EDT)

I don't see any suggestions to make it more complete. I only see indications that you do not agree with allowed content. If you think it's hard to quantify the last 2 points of commonly used, then I say the first one is hard as well. It's not like everyone's on at the same time, on the same server, in the same district. So yes, there's always a degree of subjectivity. And builds themselves are subjective. Your suggestions for reworking the sample pages are conflicting. How can you remove example builds yet explain strategies? As you talk about skill interactions and synergies between skills, you're talking about a build; you're just trying to illustrate it in a paragraph of text rather than a simple table. Do you consider this a role guide? If yes, do notice the listing of key skills and sample skill sets and the possible variant kill listings. That's a darn good example of what we're trying to achieve with this policy.
You have to understand that we'e not trying to get rid of builds and skill bars. We're trying to make it such that nobody can arbitrarily put up a skillbar and call it a build. There has to be an actual level of notability (that's where consensus/majority comes in). There has to be an in-depth analysis regarding it. The level of wordiness we're encouraging/enforcing is also meant to be a deterrent to potential "raw build posters".
I see the skill bars as a means of illustration; it is the best possible way to show a build. Even if we disallow skill bars, what purpose does it serve besides forcing all readers to extract skill names from all the long paragraphs? But, since the primary concern now appears to be skill bars, would you find it acceptable if we disallow any form of example skill sets and only allow analysis on the concept and the skills involved? If you're only concerned about what will happen because of what did happen in GuildWiki, my response is: you won't know if you don't try. -- sig 02:12, 27 April 2007 (EDT)
Just to clarify something, don't say "[ the MM guide ] is a darn good example of what we're trying to achieve with this policy", because it's not exactly true. Here it seems everyone wants something different, even between those that support the policy.
You, Aberrant, want General minion mastery guide.
Vallen wants Barrage ranger.
Xeeron wants Starburster.
See the discussion at Talk:Barrage ranger, they explicitly don't want the same as you. The MM guide is a very inclusive and very detailed article. Starburster is just a build. The Barrage ranger page is somewhere in between the two. Everyone's after some different ideal. --Dirigible 03:31, 27 April 2007 (EDT)
Ok, now I see the meaning the behind your earlier question. Ok, and now I see the reason why this couldn't be made policy. Apparently, the content itself is not finalised. I take back my misinformed lengthy response to Erasculio. Thanks Dirigible, now I get where Erasculio was coming from. Apologies all. No offense intended. I was pushing too hard.
Let me restate my stand then: I still think the general MM guide is what can be achieved as a role or build concept guide. I think Barrage ranger is borderline. A more general "Barrager" is much better, i.e. using the bow to inflict area damage. Starburster, Frenzybot, Shock warrior, ... in my humble opinion, these are, as mentioned before, verbalised forms of the builds in GuildWiki and should be disallowed. Nobody asks for a "Starburster" or a "Frenzybot". Nobody discusses these terms in forums. I agree with Valen below that the emphasis should be on the Role, not focused on the skill being used. And now, after clearing my head a little, I'm in complete agreement with Erasculio in that articles like Starburster, Frenzybot, Shock warrior are nothing more than subsets of a role, a build concept; i.e. a concept of a point-blank range nuker, a knock down tank/offense. Yep, I'm much clearer on my own stand :P I have no idea why I misunderstood things just now... thanks Dirigible. And err.. no, I don't have an evil twin >.< -- sig 04:04, 27 April 2007 (EDT)
I agree with Aberrant : D I really like the MM guide, and I think that's an example of the best we could do (although, like Aberrant said and like has been said on the Barrage talk page, it's what we "could" create, not what we "have" to create - as in, I would not mind if we don't expect all guides to be that long and complete, although it is a goal to aim for). But I really think we should aim more for roles than for builds, avoiding what Aberrant defined as "verbalised forms of the builds" (that's a very good definition). Erasculio 09:10, 27 April 2007 (EDT)
At least we know where everyone stands now. I take it from the above discussion that you both (Aberant and Erasculio) want lengthy guide articles, but nothing close to build articles, so your prefered build policy would be along the lines of "no build articles at all".
Just as a note: I play various forms of PvP regularly and I have never, ever seen "LF point-blank range nuker", whereas I have seen plenty of "LF Starburster", so people DO ask for it and not the other. --Xeeron 10:28, 27 April 2007 (EDT)
In that case, you have a perfectly good argument about commonly used right there. A couple of other PvP players supporting you and we'd keep the Starburster page. And we'd still have a page regarding the point-blank nuker role that will likely list the Starburster as either a variation or an example. Everything falls into place now right? -- sig 22:07, 27 April 2007 (EDT)
I've been reading over this discussion and would just like to add one thing. As a casual player and wiki user when I come looking for a build or setup I often want an example skillbar. I don't really care to know, for the most part, why all the skills work in exactly what combinations and often don't want to sort out which 8 skills I need. While I'd read a guide or explanation to get an understanding of the build and how to use it the skillbar is something that I find quite useful. Even if its just a sample and I end up modifying it later. It seems, from the discussion, alot of people are against this but I don't understand what the problem is with including one. It doesn't require people to vote on its usefulness, its relatively simple to read the article and demonstrate the example bar fits the description/guide. It makes it easier for casual players, at least in my view, to find what they're looking for and provided them with a way to learn (by reading the guide) if they want to know more. Lojiin 11:33, 27 April 2007 (EDT)
Which is exactly why the policy as it is allows for links to example builds that exemplify it. :) -- sig 22:07, 27 April 2007 (EDT)

Sorry if I jumped in there it's just that these build discussions have been going on _forever_. I just want something in place. There are so many topics and so much discussion across 2 wikis that I can't tell which way is up at this point. All I am suggesting is that a Role guide with a few links to example builds or similar role guides be put in place. I guess I misunderstood what was on this project page. --File:VallenIconwhitesmall.JPG Vallen Frostweaver 11:52, 26 April 2007 (EDT)


Ok in above discussion, I see that some people (e.g. dirigible) want guides discussing in length a certain strategy, along the lines of General minion mastery guide. Others (e.g. me) want shorter guides focusing on how certain skill interactions work, like in Starburster, yet others again (e.g. anon on Talk:Barrage ranger) want the graphical detailed skill bars and attribute lists of guildwiki. That makes me wonder whether we should have more than one layer. The reason being that all of these are not mutually exclusive, however it would be hard to make them coexist with the same formatting. However it is entirely possible to have some big strategy guides, which link to more specific build guides explaining skill interactions, which in turn link to detailed "ready-made" example builds with skill bars and attributes.

Opinions on this? --Xeeron 08:34, 28 April 2007 (EDT)

sounds good. I think it's one of the few ways that I think that we can make this work. It's like an onion... or is it an ogre? --File:VallenIconwhitesmall.JPG Vallen Frostweaver 09:12, 30 April 2007 (EDT)
The only problem I have is with falling into the temptation of just making a build in verbalised form. Not only because I think those are limited, but also because I, personally, don't think they are as helpful to a new player as they could be. I'm against an article with only a skill bar (be it shown or described) and only a few notes on how to use those skills as opposed to an article describing a role, how to perform that role, which skills could be used and how, the most important skills sinergies and some example skill bars - the former would let a player see what a build is, but the later would let a player understand that build, and so have an idea of how to take one of the examples and adapt it to his liking while still keeping the same role in mind. Both are better than nothing, but I would rather have the more complete approach - those who just want to see the skills used could skip to the example skill bars, but the full content would be there for those who wish to see it. Erasculio 11:24, 1 May 2007 (EDT)
So you can start reading the strategy guide, then (if interested) click on the link to the build guide and (if still interested) to the example build with skill bar. --Xeeron 17:40, 1 May 2007 (EDT)
Might be possible. But given that you will have most of the discussion on the role guide, would this mean that each of the individual build guides are likely to repeat most of the stuff on the role guide? But only in shorter form?
Also, is there going to some sort of limit or restrictions on the number of "ready-made" example builds? I'm seeing the potential for this "layer"-based approach where a role-guide would suddenly have dozens of links to different skill bars. -- sig 09:48, 2 May 2007 (EDT)
That's the problem I have with the idea of layers. I think it would become a bit too redundant, and that it would be hard to settle the number of example builds (if each has a different article for itself). I would rather have a single plage with all the information, including a few example skill bars, or two pages with one being the role guide and another being just the build with stats information (attributes, skill, equipment). Erasculio 10:25, 2 May 2007 (EDT)
Hmmm, maybe I am not clear enough: Example build = Attributes+skillbar+equipment. Nothing more. The full discussion is in the build guide.
On the number of example builds, I'd go with what was in the policy a while ago: " The number of these builds should be kept as small as possible". --Xeeron 13:51, 2 May 2007 (EDT)

People want builds, how do we provide them

Please take a second and follow this link. Currently builds are the third most looked at article here, behind the main page and armor. That is despite the fact that the build article not more than a glossary entry. This clearly shows that our users want us to feature builds and, given that it is unlikely that anyone comes back to view a glossary article repeatedly, there are thousands or tens of thousands of such users. Please share your ideas on how we can meet that demand. You can put forward a new idea, cite any of the old ideas on this talk page, refer to policy proposals, other wikis, whatever you want, just please dont use the defeatist "we cant do it" agruement. --Xeeron 14:05, 24 May 2007 (UTC)

I like builds and I agree that on GWiki it was a flub in many ways but a success in others. Currently, I've been watching the progress of the PvX Wiki (or what I call Buildwiki) and it's been coming along nicely. Perhaps something along those lines or even directing people to that site? We can do it! <jk> --File:VallenIconwhitesmall.JPG Vallen Frostweaver 14:59, 24 May 2007 (UTC)
Afterthough - if it'll bring in more traffic then I'm for it at this point as there seems to have been a drop off of participation on articles on this site and not enough little things are getting done now. More people should help to get the info posted so we can actually rival GWiki not that I'm trying to set this site against them. --File:VallenIconwhitesmall.JPG Vallen Frostweaver 15:01, 24 May 2007 (UTC)
People got spoiled by using GWiki. At most, just put links there to PvXwiki and, it's not like we NEED to generate pageviews. -- CoRrRan (CoRrRan / talk) 15:06, 24 May 2007 (UTC)
That would suggest that PvXwiki is somehow inherently better than GGW, able to do stuff we are not. I dont see any reason why that should be. We can discuss why I feel that gwshack has a crappy interface is totally lacking organising structure (like our links and categories) elsewhere, but I specifically asked what we can do. If you feel that being useful to our users is not our main objective, then I beg to differ. --Xeeron 15:28, 24 May 2007 (UTC)
Well, we can just link to those sites. I don't see why a link is not "being useful". But your question feels like you think the logical answer is to provide builds for those users. And why not continue from where it was left off under "Layers" above? There doesn't seem to be any objections since then.
And just a side note to Vallen, I think bringing in more traffic by creating a builds section will not increase participation significantly. On GuildWiki, there's a whole subset of users that edits the Build namespace almost exclusively. -- sig 16:29, 24 May 2007 (UTC)
I know. I used to be one of them. --File:VallenIconwhitesmall.JPG Vallen Frostweaver 02:59, 25 May 2007 (UTC)

I think a partnership with "Buildwiki" would be the best course of action. Maybe if the top 10 or so most veiwed Buildwiki articles were put on GW wiki, it would increase traffic. There would be no elitism, as the only people determining what builds were featured would be the palyers veiwing the wiki themselves, and no "bad builds" as the msot veiwed builds would most likely be those that have their names thrown around in HA all the time.--Mortazo 15:46, 26 May 2007 (UTC)

The idea to just link to external sites have already been proposed long ago. It's just that proponents would rather the builds be hosted on this wiki. -- sig 02:27, 28 May 2007 (UTC)
If the official wiki links to another site for builds, that site would need to be official too, ie ANet should start their own build wiki. Ofcourse we can discuss if it is easier to start a new wiki or have builds here, but it seems clear to me that builds are wanted in one way or the other. -- Gem (gem / talk) 04:11, 28 May 2007 (UTC)
We should not link to PvXwiki for builds. For one, their administration is completely bonkers. Second, they're not even an official fansite -- they're barely off the ground.
For me, the question is not Can we provide builds?, but should we? It is very clear that some system of builds can be placed here on the wiki, and it's even clear that we could make such a section pretty popular. What isn't clear is how useful that section would actually be. While I'm not opposed to putting builds on the official wiki, I think we should only do so if we can do it better than any fansite could. If we cannot, then perhaps a list of official fansites that provide build databases would be most helpful.
Tanaric 00:02, 30 May 2007 (UTC)
In regards to "should we" - I've always seen GWW as primarily a reference source, and in that capacity I believe it behooves us to offer, at the very least, information about "buzzword" builds - common builds that an average player would have at least heard mention of. However, I think it's essential that we limit it to only objective reporting - including attempting whenever possible to omit things that are often contested such as exact skillbars/attributes/equipment. I think that any build articles we choose to include should summarize and relate only the concepts of a build and general implementation thereof, not step-by-step directions or individual specifications. It's simple to check the former two for correctness (verifiability), whereas the latter are both subjective and much more difficult to check as there are many possible permutations. Aiiane-a.gif (Aiiane - talk - contribs) 00:16, 30 May 2007 (UTC)
Welcome to the roles camp :) But that's already been brought up long long ago. The arguments against it is that they're not useful to people who don't want to read an analysis of a build concept. (I support roles, but some compromise in the section above has been proposed). And then there's all the arguments on what kind of builds do we allow... -- sig 01:09, 30 May 2007 (UTC)
No builds! Save the recent changes page! -FireFox File:Firefoxav.png 03:02, 30 May 2007 (UTC)
Until someone comes up with a better way to assess and present builds, then none at all. - BeX 03:11, 30 May 2007 (UTC)
PvXwiki is a new wiki that has (as far as I can see) yet to be recognized by ANet. I'm still mostly against having a dedicated "builds section" on this wiki, especially with so many existing resources available (being PvXwiki, teambuilder, gwshack, gwguru, etc...) and even the official GW site even has archives of historical builds. If anything, there can be a few subpages documenting those historical builds here as well, but in general, I don't see any real reason to have a builds section here to create more havoc. Yes, a Wiki is a pretty good place to host builds, but there just isn't a need to have one here. — Rapta (talk|contribs) 03:26, 30 May 2007 (UTC)

Sorry to interrupt, but so far, only one person (Aiiane) has responded to my question at all. I specifically want to know how to provide builds (given the assumption that we will have them) and specifically not whether we should have them. Yet everyone, guided by instincts honed in years of build policy debates, I have no doubt, jumped on the second question instead of the first. --Xeeron 11:29, 30 May 2007 (UTC)

If we're not sure we should have builds on the wiki, then there's no point in figuring that out, at least at the moment. I still am a fan of the "guides, not builds" concept, and I kind of like the way we've implemented it in a couple of articles - but a builds section, where people can post their own builds (guildwiki style, or, at least now, PvXWiki style), I'm pretty sure I'll never support. Honestly, I don't really like changing the subject away from whether we should have them or not; as you said, it's assuming that we will have them, which kind of gives a bias to the entire discussion. MisterPepe talk 11:33, 30 May 2007 (UTC)
The reason is very simple: Look at the around 100 pages of discussion already spend fruitlessly on the "whether" question. Furthermore, I want to be able to discuss how builds could look like without people spreading negativity in every second comment. "but a builds section, where people can post their own builds (guildwiki style, or, at least now, PvXWiki style), I'm pretty sure I'll never support" is fine and dandy, but if we decide that how we want to present them is NOT to letting people post their own builds, then it is off the point and distracting from the discussion. --Xeeron 11:43, 30 May 2007 (UTC)
As I said, I feel shifting the topic to "how" biases the discussion - it's a logical fallacy - see the red herring argument. It also just doesn't make sense to me to waste time on something that may never be implemented due to lack of interest, so I don't really see why we should figure out details of making it work until consensus backs the idea. MisterPepe talk 11:49, 30 May 2007 (UTC)
I *want* the discussion to be biased, because discussing how to implement builds with people who dont want to implement builds simply does not work. If you feel this is a waste of time, you are free to not reply.
PS: Deciding HOW builds will be implemented is hardly irrelevant for the decision whether they will be implemented. Btw, if you want to play "spot the fallacy", start by looking at the huge straw man in your own post. --Xeeron 12:04, 30 May 2007 (UTC)

Quoting Xeeron: Sorry to interrupt, but so far, only one person (Aiiane) has responded to my question at all. I specifically want to know how to provide builds (given the assumption that we will have them) and specifically not whether we should have them.

And this is because people like me, probably agree with your opinion and are showing support of your question the only way they can. I, personally, don't have any ingenius ideas to offer that will make builds a great thing on here but I can still say something about it and I did. Sorry if I didn't answer your question, but I support the asking of it as I'd like to know as well. --File:VallenIconwhitesmall.JPG Vallen Frostweaver 12:10, 30 May 2007 (UTC)

Hmm... I thought I answered your "how". Suggesting that we provide links to guide people to good builds databases is not a valid answer? *shrugs* If Aiiane's response is what you're looking for, then you're just ignoring my question regarding the previous section. Wasn't there at least 3 different ideas on how builds can be provided to users? -- sig 13:40, 30 May 2007 (UTC)
I am sorry, I forgot to count you, you did answer to the question. I did not leave you out because I like Aiianes answer better than yours. --Xeeron 14:03, 30 May 2007 (UTC)

Why that question?

Let me quickly explain why I asked that question (and still would be happy for answers). So far most of the suggestions how to provide builds have been made with the explicit condition ("how do we get the anti-build crowd to allow builds?) in mind. That, imho, is the wrong concept. Everyone interested in builds should try to come with the best concept for builds that we can use given the wiki allows builds. That is without having the fact of how to get builds on the wiki in mind all the time.

Then, once those people have discussed builds (without having to argue in favor of allowing builds all the time), we come up with some "best way to provide build". Then we take that best way and decide whether it is good enough. If it is not, no builds.

Let me write down two over-simplified examples of build discussions. This is how build discussions are now:

  • User A: We should rate builds.
  • User B: I think that rating builds is not appropriate.
  • User C: Look at guildwiki, no builds here at all!
  • User A: Then how about putting builds into user space and link from the main namespace?
  • User D: Hmmm, would that not be superficial? We could put them into main namespace right away, if we will have redirects anyway.
  • User C: No builds at all, dont go there.
  • User B: Then how about having them in categories?
  • User C: Just get rid of all builds, they only mess up recent changes.
  • User D: No they dont! Err, what did you say, no categories dont work either.
  • User C: And they dont have to work, since we dont want builds in the first place.
  • User A: So what are the advantages of allowing any build, not only rated ones?
  • User C: The mess is even bigger and we get a build wipe earlier.

I want to get rid of unhelpful comments till the end of the discussion:

  • User A: We should rate builds.
  • User B: I think that rating builds is not appropriate.
  • User A: Then how about putting builds into user space and link from the main namespace?


  • User A,B,D: Ok this is our grand build design!

Then either:

  • User C: Hmmm this could work, lets try it.


  • User C: It still sucks, no builds for us.
  • User A,B,D: :cry:

--Xeeron 14:19, 30 May 2007 (UTC)

I'm not being contrary, Xeeron, but personally, I think the best way to offer builds necessarily involves some defined method of community feedback on builds owned by individual submitters, and I think the only way to do this is to use a custom software solution, not a wiki. So, for me, the best way to do builds is to do them somewhere else. If our goal is to provide our users with builds, it's quite possible that the best way for us to do so is via a set of external links. I know this isn't exactly the sort of answer you're looking for, and I won't belabor the point, but I just wanted to point out that answering your question while maintaining a no builds on the wiki stance is not impossible. —Tanaric 14:36, 30 May 2007 (UTC)
So you would be a perfect example of User C. And you'd fit in perfectly at the very end of my second example. The problem is that we never get the start of my second example running, because it always turns out to become the first one =) --Xeeron 15:02, 30 May 2007 (UTC)
Perhaps there is a reason for that -FireFox File:Firefoxav.png 15:05, 30 May 2007 (UTC)

We just need something that fits the "this could work, let's try it" part BUT we will undoubtedly end up with a whole bunch of "still sucks, no builds" regardless of the method or the "how" as you can never please all the people all the time and there's always "C" people out there to guarantee that. --File:VallenIconwhitesmall.JPG Vallen Frostweaver 19:01, 30 May 2007 (UTC)

It seems readily apparent simply due to the existence of this discussion that there is at least some community interest in having builds on this wiki. That being the case, my opinion is that there's no need to drive traffic to another site when we can provide builds here. There are, and I think there will always be, some people who are not happy with any system that gets implemented. Be that a system where there are builds or not builds or one approach versus another. I think there is a way to accomodate the majority of the people on the wiki and who use the wiki its just a matter of how. That said I think the wiki needs a system that includes at minimum :

  1. A way for people to contribute builds.
  2. A way for acknowledged useful builds to be collated.
  3. A way for people to ignore builds.
  4. A way for people to learn about builds (i.e. what makes a good build for a given scenario).

Now I'm not a wiki expert by any means but I would assume that with with existing technology there is a way to accomodate all of those. Point 3 seems to be the most contentious at present, but I don't see why a filter could not be in place to exclude a build category (or namespace is it?). People could exclude them from searches, the recent changes list, or anywhere else (though in some cases that would simply mean not following links) via a set of preferences. Also, something that I personally would find useful, is being able to pull build templates down from the wiki from my personal user space. (Assuming I have a wiki login). This is handy as I use more than 1 computer and I currently have to copy and paste build templates around. While this isn't a big deal, it would be fairly straightforward (now that the wiki integration is in the game client) to have a user page (or other page) that I can pull up and choose to load a template from (or simply copy/paste from).

In response to Tanaric (and other's I think) opinion of "should we" provide builds. I think if there is a community interest in having them, that we should. The wiki is, after all, a tool for the community as a whole. I don't think its appropriate to include and exclude community interests excepting only things that break the EULA or are inappropriate conduct/behavior.

To specifically answer Xeeron's question, I think a tiered approach, as discussed farther up this page, is most appropriate. It provides space for point 4, where people can learn about builds not just copy/paste cookie cutter style builds. It provides specifics for people who already know the ideas/concepts but just want a build template. Its also flexible as layers can be added or subtracted if different needs are found. Lojiin 20:40, 30 May 2007 (UTC)

I disagree with your response to my "Should we" question. There is a community interest in having Flash-based Guild Wars guides and Guild Wars parody comics, but that does not obligate the wiki toward maintaining a system where they can be created and stored here. Perhaps most relevantly, there is definite community interest in having a way track to track prices of in-game items on the wiki – the request has been made at the GuildWiki many times – yet that's something we definitely don't want on the wiki.
If we take it a bit further, there's also community interest in sexual stories about Gwen. I won't post a link to these, but have a look through the history tab of the GuildWiki's Gwen article and you can see that they have in fact been posted to the wiki and deleted. Now, perhaps the sexual nature of the story posted breaks the EULA, but we also don't allow even regular, non-sexual fan fiction to be posted to the wiki, regardless of the community interest in the material and the great medium we have to present it.
My point is simply that it absolutely is appropriate to include and exclude community interests, and we do it all the time.
Anyway, I encourage work on Xeeron's question, as I'd like to see a build system that works. It's entirely possible that I'm wrong and that such a system is makable for the wiki that surpasses any current build system on the Internet.
Tanaric 00:25, 31 May 2007 (UTC)

My answer

I took my first stab at this. Please see: Guild Wars Wiki:Policy/Builds/draft B. --Rezyk 01:40, 31 May 2007 (UTC)

I think it's a pretty good combination of some of the more acceptable ideas discussed in some of the sections above. In short: Common builds as build concept articles, user builds in user space with user-specific direction and vetting but pre-defined categories. -- sig 02:08, 31 May 2007 (UTC)
Some pretty new and pretty good ideas in there Rezyk. Primarily, splitting builds into those which will be searched by users because of their noteworthyness and making them regular articles and into those which allow for new ideas and relating them to user space seems very sensible. "Directing users" looks like a way to stop heavy arguements on one build: Unlike the main namespace, the user namespace always belongs to one user, so there is some version of a final arbiter (namely the user who's namespace the build is in gets to have the final say).
The idea to have different competing classification schemes looks intrigueing. I guess and hope that eventually it will settle down on the one or two best systems to reduce complexity, but it allows for disagreeing editors to set up their own ranking scheme and try to do better than the existing ones. So thanks for your answer, this was what I was hoping for: Someone comming in with new ideas =) --Xeeron 09:42, 31 May 2007 (UTC)
But if we decide to do a GuildWiki and wipe all the builds for whatever reason at some point, then it won't be as simple as clearing a namespace. --Santax (talk · contribs) 09:48, 31 May 2007 (UTC)
I think Rezyks draft is a great concept. It puts the responsibilities on many shoulders and provides a good way to index the builds.--Betaman 11:38, 31 May 2007 (UTC)
I think I can actually support something like that, which is weird considering how against builds I've been ;) It incorporates the best parts of the "Guides, not Builds" concept (which makes sense, especially in some of the PvE/PvP strategy/tactics articles), and still allows for user builds to be posted (as much as I dislike this idea, I understand that people would like it - I feel regulating them to the User: namespace, so that people can filter them out and it's up to the individual users to maintain is an almost ideal solution). Nice work, Rezyk. MisterPepe talk 17:27, 31 May 2007 (UTC)
Santax: A similiar system has been proposed in the GuildWiki so it's not so new, but it's the best idea on a general level that I've seen. -- Gem (gem / talk) 18:55, 31 May 2007 (UTC)
How can there be a builds wipe if Rezyk's draft policy doesn't even allow builds in the main namespace? And the current GWW:USER allows builds in user namespace. Looks like receptive responses so far. Really good work Rezyk! -- sig 07:06, 1 June 2007 (UTC)
I think this draft, aside from small touch-ups here and there, is something I could support. Go to Aiiane's Talk page (Aiiane - talk - contribs) 20:29, 4 June 2007 (UTC)
iawtc - BeX 04:48, 5 June 2007 (UTC)
I had to look that up :D For those as clueless as I am, from W:IAWTC, it means "I agree with this comment". -- sig 05:30, 5 June 2007 (UTC)
:P - BeX 05:54, 5 June 2007 (UTC)

(reset indents) Hmm, so from what I see so far, very positive responses. Should we propose to move this from draft to policy? --Xeeron 09:41, 5 June 2007 (UTC)

Proposed policy - I support the move. I still think it requires some refining work and more feedback. - BeX 10:45, 5 June 2007 (UTC)
It looks interesting but a bit unwieldy imo. If you think about your average user jumping on here that may have an interest in posting a build I doubt they'll want to read through several pages of build policy (including the links) and if they do, they will probably read only the parts that they want to or that would allow them to accomplish what they want. I do like it but it's tough to comprehend all angles at some points and I think it could use a little spruce up or something before going into full effect. Looks good for a proposed policy. --File:VallenIconwhitesmall.JPG Vallen Frostweaver 11:22, 5 June 2007 (UTC)
Ok, I moved over Draft B to the main policy article (which is proposed policy, not draft). Now get going with the refining work, or mention what needs to be refined here =) --Xeeron 12:33, 5 June 2007 (UTC)