GuildWiki talk:Style and formatting/Builds/archive 2

From GuildWiki

Contents 1 Guide needs a lot of updating 2 New Infoboxes 2.1 On the parameters to the template 2.2 Second thoughts 3 A new proposal for attribute boxes 4 "Hench" 5 Restarting the build-stub debate 5.1 Vote 5.2 Discussion 6 What is with this page? 7 Per last revisions

[edit] Guide needs a lot of updating

This guide is seriously out of date.

Also, I suggest we add some additional clutter to the articles. You can see my proposal on User:Stabber#Tools for the GuildWiki Metagame. — Stabber (talk) 22:55, 9 April 2006 (CDT)

(This is a repost from Stabber's talk page, since it's more appropriate to put this here.)

Those templates (or, I suppose they're proto-templates at this point) seem useful. I would suggest flattening them out a bit more (so they're more like 1-2 lines of text in height) and changing up the icons a bit. That red exclamation point doesn't seem quite fitting. I'm not sure what a better alternative might be at this point, but I'll let you know if I think of anything. (Are they icons for Factions/Prophecies? Hmm, I guess we could make small ones based on the character creation intro art: how about some kind of arena-looking thing for Prophecies and an Asian-temple-looking thing for Factions?) --130.58 23:04, 9 April 2006 (CDT)

Very much out of date. As someone trying hard not to read Style and formatting, I didnt even know it was around. --Xeeron 07:25, 10 April 2006 (CDT)

← Moved from User talk:Stabber I think the point of This build uses Prophecies-only skills is not that you HAVE to have ch1 to play it, but that you DO NOT have to have ch2 in order to. if a build contains ONLY one chapter's skills, it is not a limitation, but the thing that will allow more players to play it. I would make the This build uses skills from multiple campaigns tamplate red, while the others green, or green and blue, in addition of changing the text. Anyway, this is all very cleaver and useful. :] Foo 01:26, 10 April 2006 (CDT)

I really really like the idea of the templates, I (at their current state) really dislike the content and appearance.

• First, they are to big and to bright. Unlike the big BEWARE THIS IS FACTIONS CONTENT AND NOT FINAL template, they should rather be smallish notes:

1. "This build uses Core skills"
2. "This build uses Core and Factions skills"
3. "This build uses Core and Prophecies skills"
4. "This build uses Core and Factions and Prophecies skills"

• Then I dislike the sentence "The opinions held by the author(s) of this article are not necessarily shared by this wiki or the general Guild Wars community." a lot. This is a wiki and each article, including builds, can be freely edited by anyone. So if the opinions are not shared by you, you should change the build (or discuss it on the talk page). I would prefer something along the lines of: "There are many different builds which may or may not suit you" --Xeeron 07:34, 10 April 2006 (CDT)

But if I were to simply edit any article to add my pov, then I'm still leaving the article with some bias. There are many builds that I simply disagree with, but I am not going to edit them to conform to my narrow worldview. I think subjective content in the wiki should be clearly marked as such. — Stabber (talk) 14:47, 10 April 2006 (CDT)

[edit] New Infoboxes

Proposal: list the campaigns that a build requires. I have the following template suggestion: User:Stabber/build requires. To see it in action:

• Only Prophecies

This build is designed for accounts with access to the following campaign(s). The Prophecies Campaign Editors: please refrain from linking skills, items, etc. from other campaign(s).

{{user:stabber/build requires|prophecies=yes|factions=no}}

• Only Factions

This build is designed for accounts with access to the following campaign(s). The Factions Campaign Editors: please refrain from linking skills, items, etc. from other campaign(s).

{{user:stabber/build requires|prophecies=no|factions=yes}}

• Both Prophecies and Factions

This build is designed for accounts with access to the following campaign(s). The Prophecies Campaign The Factions Campaign Editors: please refrain from linking skills, items, etc. from other campaign(s).

{{user:stabber/build requires|prophecies=yes|factions=yes}}

• Neither campaign (!!)

This build is designed for accounts with access to the following campaign(s). Editors: please refrain from linking skills, items, etc. from other campaign(s).

{{user:stabber/build requires|prophecies=no|factions=no}}

— Stabber (talk) 13:58, 10 April 2006 (CDT)

Hello? Some feedback on the new design would be nice, or I will simply assume that my proposal is 100% acceptable by everyone. — Stabber (talk) 00:55, 12 April 2006 (CDT)

I would prefer making it more strict, as in "This build uses ONLY skills from Faction" and "..from Prophecies" and "This build uses skills from BOTH Faction and Prophecies campaigns, and hench require both chapters", so it will be clearer that a build is set to work in a standalone chapter, and should not be "conteninated" with skills that will constrict it to account of both chapters:

This build uses ONLY skills from the Prophecies campaign.

This build uses skills from BOTH Faction and Prophecies, and hench require both campaigns.

Foo 18:50, 17 April 2006 (CDT)

My earliest suggestion had some reddy boxes, but people disliked the "if you use this build you will DIE!!!!" message that such a garish color seemed to project, so I toned it down to an antiseptic blue. Furthermore, I think any such infobox we design should be future-safe, i.e., not mention "both" campaigns. My proposed template is infinitely extensible in this regard using MediaWiki 1.6 magic. — Stabber (talk) 23:39, 17 April 2006 (CDT)

But can you see that thing that I'm afraid of? that someone will say "Oh! that build could use the %^#%^ skill! I'll add it and just add 'Faction' to the list in this banner!". another thing is that those banners should contain a category link. a compromise could be something of the sort of:

This is an ----insertintamplate---- build, and require only skills from that campaign.

This is a multy campaign build, and hench could not be played with any standalone campaign.

Those, ofcourse, and only apearences, and the propare tamplates should be writen. I would still keep the red. Foo 03:46, 18 April 2006 (CDT)

I think what you are afraid of is something wikis are already good at preventing -- edits that don't fit some guideline. I think infoboxes in articles should be informative to the reader of the article, not the editor. As a reader, any part of the page that screams for my anttention will get an unusually large amount of it -- and these boxes don't need the undivided attention of a reader. Similarly, any text that cautions me in strong terms had better tell me something vitally important, and I don't think these boxes are vitally important. The worst that can happen to me is that I won't be able to play a build. I might (weakly) agree with the red version of the box with a strongly worded caution if placed in the talk page of a build article. — Stabber (talk) 10:31, 18 April 2006 (CDT)

I'm afraid of being looked apon as a second grade player if I do not buy both chapters. I accept the idea that this wiki is for the full GuildWars experience, but I would like us to try to prevent it from becoming the wiki of only the full GuildWars. Foo 12:44, 18 April 2006 (CDT)

It's a valid concern, but we can simply institute a policy that finished build articles will not accrete junk from other campaigns. I really think that policy is best handled invisibly rather than with infoboxes. — Stabber (talk) 12:49, 18 April 2006 (CDT)

I have attempted to address a part of your concern. Your thoughts on the new design? — Stabber (talk) 11:26, 19 April 2006 (CDT)

I like that. It projects the policy I would want us to have. yet, I think the font should be a little bit bigger ;] Foo 11:46, 19 April 2006 (CDT)

You know what, after the seperation you have made between info for the reader and for the editor, yea, this seems correct. Foo 11:48, 19 April 2006 (CDT)

[edit] On the parameters to the template

Only thing i would recommend changing in that template would be to remove the =yes and =no if it is listed it is included, if it isnt listed it isnt included.

Factions and Prophecies {{user:stabber/build requires|prophecies|factions}}

Factions {{user:stabber/build requires|factions}}

Core only{{user:stabber/build requires}}

This way we can add to the template down the road as multiple chapters are released, otherwise there will alot of silly page edits to do in the future. --Draygo Korvan 14:49, 21 April 2006 (CDT)

I have tried that, and have been unsuccessful in coaxing the template mechanism to do it. I am not sure if it is possible. If you have a suggestion on how to do it, I'll be happy to hear it. By the way, the =no arguments are not required -- they're just there for show. — Stabber 14:52, 21 April 2006 (CDT)

You can do something like the attribute template system does which allows to have different amounts of attributes listed. Though it might be a little more difficult to get it to look the way you want it to. I imagine it is quite possible. --Draygo Korvan 14:58, 21 April 2006 (CDT)

Yes, but imagination is not code, unfortunately. My attempts have borne no fruit. Maybe you'll have better success. — Stabber 15:03, 21 April 2006 (CDT)

If you are talking of the commonly used attribute template as in here, then it does not do what you wish, but actually, it is about 4 different templates that vary the number of items included. surely, this way it can be done. Foo 15:18, 21 April 2006 (CDT)

The best I can come up with is:

This build is designed for accounts with access to the following campaign(s). Guild Wars Prophecies Editors: please refrain from linking skills, items, etc. from other campaign(s).

{{user:stabber/build requires alt|prophecies}}

This build is designed for accounts with access to the following campaign(s). Guild Wars Factions Editors: please refrain from linking skills, items, etc. from other campaign(s).

{{user:stabber/build requires alt|factions}}

This build is designed for accounts with access to the following campaign(s). Guild Wars Prophecies Guild Wars Factions Editors: please refrain from linking skills, items, etc. from other campaign(s).

{{user:stabber/build requires alt|prophecies|factions}}

This build is designed to use only core skills. Editors: please refrain from linking campaign-specific skills.

{{user:stabber/build requires alt}}

BUT:

This build is designed for accounts with access to the following campaign(s). Guild Wars Factions Guild Wars Prophecies Editors: please refrain from linking skills, items, etc. from other campaign(s).

Arguments in wrong order

{{user:stabber/build requires alt|factions|prophecies}}

This build is designed for accounts with access to the following campaign(s).INVALID TEMPLATE PARAMETER "flurblegloops". See template talk:build requires for proper usage information Editors: please refrain from linking skills, items, etc. from other campaign(s).

Invalid arguments

{{user:stabber/build requires alt|flurblegloops}}

We can choose to live with these problems, if you desire. — Stabber 15:28, 21 April 2006 (CDT)

Arguements in the 'wrong order' is no real big deal as long as they are listed. Authors may then chose to order them how they like, either by what they feel is importance or relevance. Obviously the error is also of no concern, I'm pretty sure someone will come along and fix it if its a minor mistake or remove it. Its perfect now =). --Draygo Korvan 16:09, 21 April 2006 (CDT)

Fine, I'll update the main template with this design then. — Stabber 16:21, 21 April 2006 (CDT)

Now we just need to update the boxes so that the margins are the same. --Draygo Korvan 02:33, 22 April 2006 (CDT)

Not sure what you're talking about. Please elaborate. Is it a problem with how they show up in your browser? If so, a screenshot or two would be appreciated. I can only test with FireFox, Opera, and Konqueror here, and they seem fine for me. — Stabber 03:14, 22 April 2006 (CDT)

In internet explorer the background around the text is white (the table element with the campaign listing), while in Firefox it is an entirely grey background. The table is not inheriting the div's background. --Draygo Korvan 19:46, 23 April 2006 (CDT)

How about now, in the most recent boxes above (the ones referencing user:stabber/build requires alt)? If this fixes it, I'll roll it out to the main template. I was not aware that IE didn't grok background: inherit. — Stabber ✍ 19:49, 23 April 2006 (CDT)

Sorry for responding so late, but its fixed. --Draygo Korvan 13:21, 27 April 2006 (CDT)

[edit] Second thoughts

After seeing it on a few build pages, I'm having serious second thoughts about it. I think these boxes are poster children for instruction creep. I think we should either get rid of them or drastically change the format. — Stabber (✍ • 2006-04-23 20:08 UTC)

Maybe they should be added some way at the bottem of the page? Foo 16:00, 23 April 2006 (CDT)

I realize that this discussion is old, but how about taking a cue from the spoiler template:

Factions only

Prophecies and Factions

Core only

--Spot 16:17, 16 May 2006 (CDT)

[edit] A new proposal for attribute boxes

I am not a fan of the syntax used for the attribute boxes at the moment. I have a new proposal: Template:Attributes. You can see some examples of its use on Template talk:Attributes.

I propose that we scrap the old templates and use this one. — Stabber 14:13, 21 April 2006 (CDT)

I will do this in a day's time if there are no objections. Object now or forever hold your piecepeace. — Stabber 16:38, 21 April 2006 (CDT)

All right, since no one objected, I've gone ahead and transitioned to my proposed design. Say good bye to [[:Template:2 Attributes]], [[:Template:3 Attributes]], [[:Template:4 Attributes]] and [[[:Template:5 Attributes]]. — Stabber 17:21, 22 April 2006 (CDT)

[edit] "Hench"

I think the red boxes should have the word "hence" not "hench".--Life Infusion 20:34, 23 April 2006 (CDT)

Those red boxes aren't being used for anything at the moment. They were just design suggestions that were not adopted. — Stabber ✍ 20:44, 23 April 2006 (CDT)

[edit] Restarting the build-stub debate

Re:

• GuildWiki talk:Community Portal/Archive 2#Clarification of policy on build stubs?
• User talk:Delia Rashesh#New builds

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

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

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

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

[edit] Vote

This ballot is not yet fixed

All new builds have to be {{build-stub}} (or similar) and undergo vetting

1. Xeeron
2. Shandy
3. (your vote here)

New builds are put into the non-stub build categories, but undergo stealth testing. Contributed builds that are found to be rubbish are ejected.

1. Stabber 10:33, 5 May 2006 (CDT)
2. --Delia Rashesh (talk) 10:46, 5 May 2006 (CDT)
3. Gem (As long as everyone has the right to stub clearly incomplete or suspicious builds)
4. — 130.58 (talk) (11:06, 5 May 2006 (CDT))
5. Skuld Same as Gem
6. Nilles
7. (your vote here)

[edit] Discussion

Copied from User talk:Delia Rashesh

If you create a new build it needs to have {{build-stub}} added to it so it can be reviewed & brought up to standard before it is put into the appropriate category, thanks & welcome! Skuld 08:59, 5 May 2006 (CDT)

Even though it's not a stub... and in the right category... --Delia Rashesh (talk) 09:01, 5 May 2006 (CDT)

On GWiki, we like to get the community to decide when a build is suitable for being a full build listed in the builds category. This ensures that junk builds do not crowd the good builds out. This is just a standard procedure and is no comment on the quality of your article of the quality or the content of your article. Shandy 09:02, 5 May 2006 (CDT)

Build-stub is a bit of a misnomer, build review would be better Skuld 09:06, 5 May 2006 (CDT)

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

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

Incidentally I'm one of the more 'progressive' users of GWiki here, and even I see the value of the build-stub category and peer review. Shandy 09:14, 5 May 2006 (CDT)

Can we peer-review without making good-intending build authors feel like they're being placed under a microscope naked? --Delia Rashesh (talk) 09:18, 5 May 2006 (CDT)

Sorry! That certainly isn't the intention. That's one of the problems with Wikis - people are always misconstruing intentions, and it leads to people forgetting to assume good faith. Shandy 09:31, 5 May 2006 (CDT)

I know it's not the intention. I am assuming good faith. But it doesn't make this process, however misguided, any more pleasant for constributors. As I said, what is wrong with tagging crappy builds when they're seen? --Delia Rashesh (talk) 09:34, 5 May 2006 (CDT)

I think, in the end, having a positive or a negative method for controlling the builds category doesn't make much difference, as long as we have a standard procedure to follow. I think our current method will produce less articles but of higher quality, whereas the proposed method will make it easier for articles to get through leading to a more encyclopedic account of builds in GW. Shandy 09:47, 5 May 2006 (CDT)

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

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

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

By the way, I agree with you. Build-stub was and is a terrible idea. I've tried to argue against it, but to no avail. Once this wrongheaded policy was set in place (before my time), people seemed reluctant to consider any other options. — Stabber ✍ 09:41, 5 May 2006 (CDT)

If this policy is maintained, it will dramatically affect whether or not I decide to publish any other builds. If this site doesn't want them, why should I waste my time writing them up? --Delia Rashesh (talk) 09:44, 5 May 2006 (CDT)

Please, don't feel obliged to post your builds. GWiki is a purely voluntary project and I don't see why anyone should do anything that they don't want to do. Shandy 09:47, 5 May 2006 (CDT)

No, I wanted to post my build to help others. But if this is the sort of welcome new contributors get, I think I have better places I could be exerting creative effort. --Delia Rashesh (talk) 09:49, 5 May 2006 (CDT)

New contributors are the lifeblood of any wiki. I personally have nothing against you, your build or your proposal. I'm not sure what kind of welcome you perceive you have received, but please don't leave out of frustration or anger already! Try to change the system, if you sincerely think it needs changing, by making a vote and talking to Xeeron (who has taken it upon himself to try to maintain the Builds section). If you notice above I already added my thoughts about your proposed method of peer review. By the way, GWiki isn't Wikipedia, but some things obviously carry across easily between the two. Shandy 09:55, 5 May 2006 (CDT)

Oh, I'm not going to leave completely, just stop posting builds, and generally stop editing builds at all. --Delia Rashesh (talk) 10:01, 5 May 2006 (CDT)

Fair enough. I'm still not sure why, though. You object to your builds being scrutinised or do you object to the way we try to ensure build quality? Shandy 10:05, 5 May 2006 (CDT)

I object to the way it's being done -- it's very un-wiki-like. Particularly in regards to the build I added, if anyone has a specific point they would like addressed, I have no quarrel. But I object to this "hey, someone needs to make sure this build isn't BS" BS. --Delia Rashesh (talk) 10:08, 5 May 2006 (CDT)

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

If I knew where to raise the point, I would. --Delia Rashesh (talk) 10:12, 5 May 2006 (CDT)

I've taken the liberty of putting out a call for votes. — Stabber ✍ 10:35, 5 May 2006 (CDT)

Thanks, I've cast my vote. --Delia Rashesh (talk) 10:47, 5 May 2006 (CDT)

END copy

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

New users do not know that builds should be marked as a stub and someone else must do it. Only a few people vote for builds to be unstubbed, so many good builds lay dormant in the stub list. --Gem 11:41, 5 May 2006 (CDT)

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

Now, where does the old system come from and why do I feel that it is appropriate: The system evolved because at first the wiki community was very opposed to having builds at all. Why was that? They had a very good point that is still valid: Unlike almost all other wiki articles, builds can not be proven to be objectively "wrong" or "right". That means they always contain opinions, which is something that wikis in general and also guildwiki try to shun. It is much simpler to maintain a good quality of articles if the truth can be proven (or the wrong part exposed). However some (including me) thought that builds are to big a part of guildwars to completely shut out of guildwiki. Therefore we constructed the builds stub procedure to ensure that (despite it being much harder to maintain the quality of the articles there), the build articles are up to guildwiki standards as well. You might disregards all this as historical blahish that should not matter here, so I will list some reasons that have nothing to do with the historical coming to be of the category:

• Guildwiki is not a place to simply communicate (builds) with other players. That is what the numberous webforums are for. It is a place where GW players should be able to find relevant information about GW.
• "Stealth testing" will not work. Why? Because even now people are much faster at contributing (their own) new builds then they are at testing others peoples builds. There is not nearly enough testing going on.
• The term "Assume good faith" is missleading and irrelevant for the discussion. Noone ever said we dont assume good faith in new authors contributions. However wikipedia does not ask you to "assume correctness" which is what your proposal amounts to.
• The fact that new authors dont now about the need to put {{Build stubs}} in not a bother as well. If someone puts up a new article in the normal build category without any formating, it usually takes less than 1 day before the article is tagged, formated and maybe even discussed. Authors dont need to know this, because others will know it for them.
• And last but not least, my main argument for the review process: Doing away with it would lead to many potentially good builds being deleted! The current review process leaves even bad articles up for a long time, giving others the change to correct them and make a better build. When every article gets put into the proper build they will be deleted much faster, leading to badly implemented ideas (that might be good as an idea in itself) being deleted from the wiki.

PS: Notice that I changed the voting topic to a more acurate description, since the build stubs process does NOT imply assuming new builds are bad. --Xeeron 12:40, 5 May 2006 (CDT)

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

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

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

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

"IMO there should not be any certain time that the votes are tallied, just check every so often and if there are a substantial number of keeps over deletes, or vice-versa, take action."

This was exactly what was done for half a year till about 5 days ago, with the result that noone bothered voting on builds. --Xeeron 12:38, 6 May 2006 (CDT)

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

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

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

Here is what I propose doing right now while waiting for this vote to clear. To at least make the current system more obvious and user-friendly:

• Move [[Template:build-stub]] to something like [[Template:Untested-build]]. (I note the wording has already been changed, this is good.)
• Change [[Template:build-stub]] to contain a stub message instead of the untested message.

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

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

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

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

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

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

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

[edit] What is with this page?

I opened up this page hoping to see something useful about creating standardized build pages and found some barely useless information--more specifically for the individual builds. So, unless any objects, I'd like to rewrite the page and set the standard on create build pages, what it should include, and how it should be set up. - Jack 20:30, 25 May 2006 (CDT)

Please do, the current is 5 months out of date Skuld 20:32, 25 May 2006 (CDT)

[edit] Per last revisions

I can see your point by moving things back to the regular standards of Introduction, Attributes & Skills, Equipment, Usuage, Variants, Notes, and See Also. But I think that it might be a better idea to leave Variants as a subsection to Attributes & Skills. I always look at Build pages and they seem a little more open to adaptation when they have optional skills listed right below the skill bar. If we moved Variants to right under the skill bar, it would eliminate the need for dedicating a whole section to it below the original usuage, and it would put everything relating to the skillset in the same place. - Jack 20:08, 26 May 2006 (CDT)

And one more thing, why do we not recommend a Introduction section? It's listed on almost every single build page, at least the newer ones. - Jack 20:12, 26 May 2006 (CDT)

Because it's stupid. Introduction sections don't need to be titled "Introduction". What else can they be? Variants should come after usage and counters. Adding variants before any discussion of the build itself just serves to confuse readers. — Stabber ✍ 20:36, 26 May 2006 (CDT)