GuildWiki talk:Builds

Category:Abandoned Builds
It has been two weeks since the first additions to this category. However, most are scheduled for deletion on Tuesday, October 17th. Thusly, on Tuesday, I will be going through the Abandoned builds which were tagged October 3rd or earlier and placing a Delete tag on them. Now is the time to speak for or against this. - Greven 14:57, 15 October 2006 (CDT)
 * Waiting on this until this is decided, then. - Greven 16:27, 17 October 2006 (CDT)


 * Booo!!! But rly I've mixed opinion on this. There are just 2 reasons that builds should not be deleted unless a fatal error (like 3 classes) occurs, and so far its weighing me opposed to deletions.  A) unfair deletions.  Like I said in the talk page a huge amount of the abandoned tags are false tags.  From hearing barek I'm knda thinking this won't matter because 2 weeks should be enough time for the author to go and remove the tag.  B) Similar builds.  This is the main reason.  Go through the wammo builds in untested.  You should find no less than 5 builds of the following form: Battle rage +liv vic/holy wrath + lots of crappy adrenaline skills.  If all are deleted, people will still keep posting this crappy build cause its obviously popular amongst a certain group of players.  But not most players, and so it gets abandoned and deleted.  And another will post it and again it'll be deleted etc.  If all 5 weren't deleted and say only 4 were, it would stop people from posting it hopefully.  And this wammo build isnt the only one its just the only one where there were freakin 5 posted!!! (Not a fifty five 15:16, 15 October 2006 (CDT))


 * A) Perhaps you missed my purge of the Abandoned category. I went through (took about 6 hours, ugh) last weekend and this weekend and removed all the improperly added tags.  Some of them, I simply corrected the date, but the vast majority were flatout removed.  I also moved the ones that had since been voted Unfavored to that category.  And yes, if someone - anyone - cares about a build marked as such... comment on it in its talk page and strip the tag.  This should be fine in theory, but I still dislike the use of it on Untested builds without the rest of the idea behind it.
 * B) Then one of the builds should be marked unfavored. It's not that difficult to get three votes. - Greven 15:31, 15 October 2006 (CDT)


 * A)Gotcha B)Eh I dunno. Anyways yeah deceased builds should be deleted.  I honestly didnt even know this category existed when I made deceased, I saw abandoned tags but I didn't see anything in "Category:Abandoned Builds" which is what I thought it'd be called, so I thought the abandoned tags meant they'd get deleted whenever an admin would see it o.o. Having said that delete away :) I'm getting a bit too theoretical here, if there's a problem we can deal with it as it comes. (Not a fifty five 22:11, 15 October 2006 (CDT))


 * Huh, almost didn't notice this. The whole abandoned thing is spread across so many pages it's very difficult to keep track of it all. I strongly oppose putting delete tags on any page due to this abandoned tag. The abandoned tag was introduced without discussion and its creator (which is you, Greven, unless I've got confused?) has said that it started being applied before the policy behind it had been decided. Thus we've got a tag that was incomplete being applied to hundreds of pages which could now be deleted thanks to a completely undiscussed but major policy change.


 * I don't have a problem with abandoned per se (although I do think that 4 weeks total is nowhere near enough time - a build should get abandoned a month after the last meaningful change and be scheduled for delete a month after that in my opinion, there is no need for such a rush), what I don't like is how all other discussion of builds is completely mired due to the perceived need for a "community consensus" while this thing ploughs ahead having come out of nowhere. Just because several high profile users seem to think it's a good idea doesn't mean it should be exempt from the established process of how policy changes are adopted, which is to say with at least some kind of discussion beforehand. --NieA7 03:35, 16 October 2006 (CDT)


 * In defense of the abandoned template: It is very much just another name for Karlos "graveyard" process, which was received quite favorably when he proposed it. --Xeeron 04:35, 16 October 2006 (CDT)


 * I just hate the way that something like R/any DUM Ranger is in there despite having 85 talk page edits and 35 article edits. That said I'm not opposed to the category, it's just a shame in some cases I guess. --Xasxas256 04:40, 16 October 2006 (CDT)


 * Well, since you do care about that build, why not simply remove the template there? Nothing stops you from doing so. All this shows the template is working: If there is a build people care about, they will notice the template and thus the build will not get deleted. --Xeeron 04:52, 16 October 2006 (CDT)


 * But if he does that then Abandoned isn't really doing it's job - there's no majority in favour of the build and it's been in untested forever, therefore no matter how good it is it's really just blocking up the system at this point. I'd prefer it if Abandoned had a longer limit but was more binding (i.e. there has to be a meaningful edit to the build, rather than someone just wanting to keep it). However, a binding template is a Big Thing and needs discussion beforehand. --NieA7 05:05, 16 October 2006 (CDT)

And no it is not karlos' graveyard Idea, do I have to quote that passage again??? He specifically said NOT to delete, which is what a lot of people are saying should be done. I'm all for this abandoned thing, but it pisses me off that I cannot add in unrefined while greven adds in this, even tho he has absolutely no vote support or anything. This is bull. (Not a fifty five 11:09, 16 October 2006 (CDT))
 * You are right, it is not exactly the same, since Karlos wanted one person to delete builds at discretion, while abandoned deleted all builds where there is no disagreement. But they both aim at the same thing: Move builds out of untested that have sat there for a long time and delete them. --Xeeron 17:22, 16 October 2006 (CDT)

Yet another build policy suggestion
I've been whinging all over the place about the abandoned template without actually coming up with any concrete ideas of my own, so more in a salve to my own conscience than in any expectation that this will get anywhere here's my idea for how builds should go through the system. It is undoubtedly slower than the current system, however I hope that by cooling down the whole process we'll get a better end result - as of now I think the mad rush to trim down the untested builds is doing real damage to the whole idea of hosting builds.


 * Category:Tested builds is renamed to Category:Favoured builds - after all, we vote "favoured" or "unfavoured", not "tested".
 * Category:Build stubs is removed as a category, as are any builds in it (into user space for stubs submitted by registered users, into the bin for those by unregistered users).
 * Category:Historic builds (that is builds which were once favoured but are now no longer viable due to changes in the game) is split off from Category:Unfavored builds.
 * Category:Untested builds is renamed to Category:Unproven builds.
 * The finer categories of build (Category:TA builds, Category:Running builds etc) are all kept, as is the idea of featured favoured and unproven builds.


 * 1) All new builds are submitted with the finer categories (see above) in place but commented out until and unless they enter Category:Favoured builds. Authors need to explain on the build's talk page what kind of environment(s) the build is intended for.
 * 2) There is a maximum of 200 builds in Category:Unproven builds at any given time. Any new builds created after this limit has been reached are automatically moved into user space (for builds submitted by registered users) or flagged for deletion (for builds submitted by unregistered users).
 * 3) Assuming the limit of 200 is not reached all new builds automatically enter Category:Unproven builds. If the build is only a stub it is marked with Template:Requires update (can anybody think of a better name?) that explains that if this build is not updated such that it is no longer a stub within 24 hours of the template being applied, it will either be moved into user space (for registered users) or deleted (for unregistered users).
 * 4) A build in Category:Unproven builds cannot be deleted for any reason (included, but not limited to, it being a "bad" build in the opinion of an admin, or being similar to others in Category:Unproven builds). The ONLY exception to this is if the build is similar enough to a build in Category:Favoured builds that it could be said to be a variant of it. If this is the case it is flagged with Template:Similar (again, can anybody think of a better name?), which means that provided there is no substantive disagreement about the matter the build will be deleted in 7 days.
 * 5) A build will automatically enter Category:Favoured builds once:
 * 6) *it has been open for discussion for at least 7 days
 * 7) *it has three more favoured votes than unfavoured votes (author's vote does not count under any circumstance)
 * 8) A build will automatically enter Category:Unfavored builds once:
 * 9) *it has been open for discussion for at least 7 days
 * 10) *it has three more unfavoured votes than favoured votes (author's vote does not count under any circumstance)
 * 11) If there are no meaningful (as set out by User:Evil Greven here: User_talk:Tharna) edits to a build in Category:Unproven builds (or its talk page) for a period of 1 month then it is flagged with the Template:Abandoned template, which explains that if no meaningful edits are made to the build for up to 1 month after that template is applied the build will be moved into Category:Unfavored builds.
 * 12) If ArenaNet alter any required skill used in a build in Category:Favoured builds in 'ANY way, that build is marked with Template:Requires checking, which explains that one of the skills used in the build has changed since the build was submitted and thus the build may no longer be viable. Any user can remove this template so long as they put an explanatory note as to why the template is being removed in the builds talk page. If the build turns out to no longer be viable it is moved to Category:Historic builds.

I don't mean to show any favouritism towards registered users here - where a build submitted by an unregistered user is deleted so should the build by the registered user, the move is essentially a bonus they get for having an account.

I realise we have far more than 200 untested builds at the moment, which could cause a log-jam when Nightfall comes out. However, Template:Abandoned has already been applied with abandon (couldn't resist). Currently builds with that template are due for deletion tomorrow - I propose that this be extended to October 27th. If no substantive changes have been made by then then those builds are to be deleted. Also on the 27th all builds in Category:Unproven builds are checked to see if Template:Abandoned can be applied to them (i.e. if there's been any substantive change to them within the last month). Unlike last time this tag cannot be removed by the author of the build just because they don't want to see their build fail - there has to have been a meaningful change for the tag to be removed.

The limit of 200 is the fairest way I can think of to stop Category:Unproven builds growing out of control. 200 is a very large number of builds (more than we currently have in Category:Tested builds), more than that is almost impossible to deal with just due to sheer volume. There's an element of first come first served, but at least this way the playing field is more or less level for all contributors. --NieA7 05:00, 16 October 2006 (CDT)


 * "Another suggestion" is a big understatement, that is actually a host of proposals:
 * tested => favored: I suggested that exact move some time ago on the categories talk page, but I was not about to start a huge crusade if with just 3 answers there.
 * kill stubs: Since that category is largely unused, I dont care a lot, but why?
 * Historic builds: That category exists, but is called Category:Archived builds
 * Untested => unproven: Why? Untested seems to be a good description to me and moving that would be a lot of edits
 * 1. That is already common practise (thought most dont read that before posting).
 * 2. This is a big new idea, let me comment below.
 * 3. ::Shrugs:: This or category build stubs, I dont care really.
 * 4. Disagree partly. It should be deletable due to similarity to both favored and unfavored.
 * 5.+6. This is current practise + the 7 days requirement. Why 7 days? I dont like yet another instance of "someone has to go back and control this"
 * 7. Agreed with this, I am both in favor of keeping the abandoned template and setting the period to 1+1 month
 * 8. Agreed as well. I thought about doing so for the last skill balancing, but in the end was to lazy to create the template and go through all skills and builds. --Xeeron 08:24, 16 October 2006 (CDT)


 * The 200 builds idea:
 * I perfectly see where you are comming from. But do we really want to give those who create a build "first" an advantage? And would this not just create a backlog of builds sitting on userpages, with authors waiting for the change to repost it once slot becomes free in unproven/untested? The author who logs on first after a move wins? I dont think that I want this. --Xeeron 08:27, 16 October 2006 (CDT)


 * Well I was thinking of the builds thing as a whole rather than as individual processes, so it was a suggestion for cradle to grave rather than just a bit (hence the duplication of some existing stuff, like 1 and parts of 5 and 6).


 * I think we should get rid of stubs as it's not something we should be promoting - we have enough builds hanging about without having to deal with skeletons as well (really we're looking for reasons to chuck stuff, not to keep it). If they've not got a home to sit in they can't sit there ad infinitum, hence a category that means deletion after 24 hours (which is not something that does or should happen to stubs elsewhere on the site). I wasn't aware of Category:Archived builds, that's exactly what I had in mind so no problems there. Somehow I'm uncomfortable with "Untested" as a category - the author should test his build extensively first, so in theory at least a build is never "Untested". "Unproven" isn't the best word for it though, to be honest I couldn't come up with much else. I don't think that being similar to another untested build should be enough for a delete - after all, if it's untested we don't know if it works, a slightly dodgy build shouldn't have the power to delete a good one by virtue of being first. 7 days is to allow for a guaranteed window of debate - some builds I'm interested in end up in favoured or unfavoured before I have a chance to really play with them, like I said at the start I reckon we'll end up with a better process overall if we cool it down a bit. It's not really a control issue (no move until page is more than 7 days old - not hard to police) for me. I'll have go at putting a Template:Requires checking together if I get a chance.


 * As for the 200 builds, it's not ideal by any means but we unquestionably do need some way of getting untested builds under control. I've seen people suggest that you're not allowed to add a build until you've voted x number of times, but I think that would be impossible to control. Builds are coming in rapidly at the moment but it'll be nothing compared to the rate that builds come in once Nightfall's out, not only with new primary professions but all the possibilities for secondaries. Basically I don't think that we'll be able to keep up, which'll mean a lot of good stuff gets lost, drowned beneath waves of tosh and duplication. 200 is arbitrary and the getting in "first" is more luck than anything else, but at least it's a more or less level playing field (though time zones may come into it). It's the only system I can think of that'd keep things down, be enforceable and not be too unfair. A backlog in user pages is surely better than a backlog in untested builds. I'm open to alternatives but I do think we need something - anything - in place before Nightfall. Things may be bad now but they could easily become unrecoverable then (there's already a backlog of Paragon and Dervish builds waiting in the wings after all). --NieA7 09:00, 16 October 2006 (CDT)


 * Just a small clarification: I meant "similarity to both favored and unfavored", not similarity to another unproven/untested build. --Xeeron 09:40, 16 October 2006 (CDT)


 * In that case I'm lost - if a build is similar to a favoured and an untested build, then it's similar to a favoured build, what's the untested one got to do with it? o.O --NieA7 16:44, 16 October 2006 (CDT)


 * I feel similarly to Xeeron on this. This is basically a good idea, and with a little tweaking could be a viable policy.  I agree that all hell will break loose when Nightfall comes out.  And I'll be partly to blame for that since I'm a buildguru (stole the name from "The Spearmen").  But a 200 build limit will stop the wiki from getting any new builds when Nightfall comes out and will cause the builds section to become extremely outdated very quickly.  If you want to get the builds section under control get more people testing builds and moving them out of Category:Untested builds so that it meets or exceeds the number that will be coming in.  If nothing else, testing builds when Nightfall first comes out should be a wiki wide project instead of just being worked on by the few people who work on it now, myself included.  So many people spend the time to create new builds, but then claim they have no responsibility to the wiki when it comes to testing them (man...we need Rapta back).&mdash; [[Image:Azroth sig.png||builds]] Azroth  [[Image:Azroth sig2.png||talk]]  13:27, 16 October 2006 (CDT)


 * I don't really like 200 builds, but I honestly reckon that we'd be better off with that (or 400, or an exemption for primary Dervishes and Paragons but otherwise 200, or basically just anything to stop the untested builds breeding still further) than we would be just leaving it as it is. My suggestion is kinda unfair (fastest wins), but the alternative seems to be everybody loses because hardly anything ever moves out of untested either up or down. The "get more people voting" thing has been tried for weeks if not months, it doesn't seem to be making any difference. Worse, some people go on a voting splurge and quickly vote on loads of builds that they neither try nor understand - Rapta made a lot of good contributions, but he also made several mistaken or seemingly unfair votes which tend not to be taken back, and thus make things worse.


 * In an ideal world more people (myself included, for all I'm preaching here) would vote on more builds, but everybody has had plenty of opportunity and very little has come of it. I think the time for encouraging people has past - with Nightfall imminent some kind of action is needed to stop untested doubling overnight. Like I say, I'm open for suggestions, but right now I can't think of anything better than a 200 cap, or something along those lines. --NieA7 18:16, 16 October 2006 (CDT)


 * Well Nei I did ask for a revote on the big 3 policies which would very quickly solve the whole problem, but people want to sit it out. (Not a fifty five 13:44, 16 October 2006 (CDT))


 * Yep, we're tired and lazy ^_^...oh wait, I voted on that <_< ummm...nevermind.&mdash; [[Image:Azroth sig.png||builds]] Azroth  [[Image:Azroth sig2.png||talk]] 13:53, 16 October 2006 (CDT)


 * Not really interested in fiddling around the edges at the moment, the whole thing is so bogged down in discussion as to be utterly immobile - hence a fresh cradle to grave suggestion. --NieA7 16:44, 16 October 2006 (CDT)

build submitting policy
Atm several policies are being discussed of how to deal with the huge ammount of untested builds. Here is my take on it: A lot of submitted builds make really basic mistakes like for example missing energy management. There is a note of this in the guide of how to make a good build but I don't think many people read it before submitting their build. Now if we were to make a policy that says that only registered users can submit a build and that this user has to test and vote on 3 other builds before submitting his own several things could be achieved: 1. We get more people to test and vote on build and the vetting/unfavoring process takes probably less time 2. The quality of the submitted builds increases because anyone who tested a caster build with 4 soul reaping as the only energy management will probably not submit such a build himself 3. The submitted builds require less clean up because people who submit them actually looked at a few other build pages before submitting 4. Less builds get submitted because people might realize that after testing a few build that their idea wasn't that good after all

downsides: probably impossible to implement, more drive-by votes just to get the required number of votes, less quality in voting

It's just my idea of how to deal with the problem. discuss. Tharna 11:06, 16 October 2006 (CDT)

This has been discussed and voted unfavored 1-6 or so :P (Not a fifty five 11:12, 16 October 2006 (CDT))
 * See This Page for the reasons --[[Image:Kitty1.jpg|24px|]] (Talk) (Cont) (Cool) [[Image:Soft2.jpg|24px|]] 11:15, 16 October 2006 (CDT)
 * On a side note I'm really sick of people voting unfavoured solely due to a lack of energy management skills. Some builds carry a lot of slow recharge spells, energy management can be as simple as letting it recharge naturally! You've gotta try it out before you can say whether energy management is an issue or not, rather than just drive-by unfavoured. --NieA7 16:50, 16 October 2006 (CDT)

Thanks
I'm sure its bad form to add a ToC item like this, but it will be easier to remove this way, plus this is easier than hunting down everyone's talk page. :) I read the build section somewhat avidly (favored builds, unfavored, etc.) though don't comment unless I feel knowledgable about a build (that is, I have tested it, etc.).

Regardless of any of that, I want to thank everyone who is putting so much effort and energy into the policy behind the GWiki build section. I really appreciate all your work, and I think it is reflected in how useful the build section is. Just reading this page indicates to me how much work goes into getting something like this right!

Thank you. --Oblio 18:25, 16 October 2006 (CDT)
 * Thank you, too! And by the way, doing what you did like you did was just the way it's supposed to be. We'd have hell of a time finding your comment without the heading. ;) If you want some build advice ahead, create your want-to-be build in your user space and have people comment on it. If the build is not very likely to be accepted to the community, you can just leave the build there without consequences and still have it documented somewhere. Pages in user namespace don't take part in the common vetting process. ~ Nilles (chat) 18:57, 16 October 2006 (CDT)


 * Yay! Someone appreciates us ^_^  All this reading and time spent posting and voting here wasn't for nothing!  Thank you for saying Thanks.  It really makes it seem like there may still be a reason to stick with this and that it’s a worthwhile endeavor (a feeling which has been diminishing over at least the past two weeks).  Feel free to comment on any policy suggestions you see here or to propose your own (as long as it’s not too similar to one already under discussion.  We've seen what happens when two very similar policy proposals come to a vote).  Thanks again.&mdash; [[Image:Azroth sig.png||builds]] Azroth  [[Image:Azroth sig2.png||talk]]  21:45, 16 October 2006 (CDT)

Getting this implemented as a starting point
So Nightfall draws closer (and with it the point where most work in the wiki will move from categorizing/making policies/discussing to creating new articles), while the end of this discussion is not in sight. I would like to get the current version of the build's policy implemented before then. It is stripped of almost anything controversial, so it should be acceptable for all apart from those opposed to any form of builds on the wiki.

Almost any proposal I have seen so far can build upon the stripped down version (as can our current procedure), I just want us to finally have a starting point.

The link in the last section points to the current procedure article (read my arguement for separating the two here), the any future proposal can either be implemented there (which I hope for), but it is just as possible to add a future proposal to this page.

One last point: Please no vote. I am very sure everyone is tired of build policy votes. I would be happy about just normal posts saying "I like this (because)" or "I dont like this (because)". --Xeeron 16:08, 17 October 2006 (CDT)


 * Looks fine to me as far as it goes, I just wonder if it goes far enough to make any difference. I'm not sure what exactly it's meant to cover though - just submitting and voting on builds, or other things like abandoned/archived templates and such like. --NieA7 03:36, 18 October 2006 (CDT)


 * Scratch that, just read Build vetting procedure. With that in mind the current builds thingy looks like it'll do the job to me, can't think of any meaningful improvements to make. With something like that it's probably best to keep it as simple as possible. --NieA7 03:41, 18 October 2006 (CDT)