GuildWiki talk:Builds

Don't like the no deleting bit, I think an extra bit, "if the build is not seen to be seen as little value to a reader" and if it is abandonned by the author (first point aswell) &mdash; Skuld 08:25, 2 September 2006 (CDT)


 * Moving this to Builds. By definition, everything in the GuildWiki namespace pertains to things on the wiki. :) &mdash;Tanaric 15:51, 4 September 2006 (CDT)

Editor's notes
I hope you don't think it too forward of me to edit this policy to be in line, stylistically, with the rest of the build articles on the GuildWiki. This mostly involved changing "the wiki" to "GuildWiki" and changing some wordings to be more personal ("the standards of the wiki" to "our standards", etc.). I also removed the NOTOC tag, as there's no reason to prevent a TOC from displaying on a policy article.

I take a great interest in policy, as everyone knows, and I'm thrilled that somebody besides me is getting involved in writing this stuff down. I also think this article is off to a good start, and I think it will become a great policy article after some of the rest of us help contribute.

One thing I think needs to be clarified.

As soon as a build is ready to leave stub status, it is placed in the category untested builds.

When is a build ready to leave stub status? That could probably encompass a whole heading by itself!

Finally, I think the policy as proposed should be subtly changed. Votes are non-binding on GuildWiki and always have been. I don't disagree with the usage of Rate-A-Build, because I believe it provides a great summary of what the build is to a reader, but I do disagree with making the results policy. I'd like to change the "X votes" for favoring/unfavoring a build into "consensus." More specifically, I think a build needs a consensus for favoring for it to become a favored build. If the vote is 50/50, and, more importantly, the discussion is 50/50, I think the build must be marked unfavored.

&mdash;Tanaric 16:13, 4 September 2006 (CDT)
 * Consensus won't be found even on builds that you will see all over in higher-level GvG if the previous votes are an indication. I think the entire process is pretty broken, but I can't really come up with something that makes sense.  I might just still be stuck in the same mindset I was in a year ago when I was arguing against having builds at all.  --Fyren 16:37, 4 September 2006 (CDT)


 * I have been giving this some thought recently. My ideas aren't really fully thought out, so please don't presume that this is a solution or anything!


 * I was wondering, if we were to think outside of the limitations of mediawiki for a moment and outside of our current system of using categories, what would the best solution be then? I was wondering if there would be some way to "rank" builds. So every build article had a number of stars on them or something, and users come along and vote and this increases the rating of the build, or it decreases the rating of the build. Having a single row of stars wouldn't make any sense, since it's not really practical to mark builds as overall builds, there should be one row for PvE, one for PvP, perhaps other rows depending on what the build is aimed at.


 * I realise this may be a pointless thought exercise, and I'm not a huge fan of voting myself, but I just thought I'd share my half-baked idea with you all to see if you could bake the other half :)  &lt;LordBiro&gt;/&lt;Talk&gt; 16:55, 4 September 2006 (CDT)


 * Tanaric: Thanks for the correction, to my utter disappointment, many many years of learning and using English have not yet been enough to write stuff the way I want it to be written, your version is much better.
 * For me the difference between a stubbed build and an untested build is formal (are the headings right, is the skill bar working without red links, is something written under 'usage') everything relating to "does the article work in the wiki as an article is supposed to work her" whereas the difference between untested and tested is down to "does the build work like an build is supposed to work in guildwars". So far there have been very few problems with getting articles from stub to untested, thx to the syntax help most people get it right when creating the article and in case they dont, it is usually corrected very fast. Most builds stuck in stubs are abandoned by the original author before the idea of the build was fully written down.
 * I wont be opposed to writing in more general form about finding an concensus (if people are worried about overly tying our hands by writing it into a policy article), but the number of votes needed should be written down somewhere (unless the voting procedure is completely abandoned). There have been several and repeated problems which all did arise from the fact that there was no such exact number written down and people disagreed over the amount of votes needed/felt treated unfairly.


 * Fyren: I agree that the vote process is not perfect. However it is far better compared to what we had before and I have yet to hear a better proposal (exception, see below). I feel that the number of visits on the build page show that they are a popular and demanded feature of the wiki and unless I see some better way to organise them, I will defend the voting process.


 * Biro: That is a very nice idea (reminds me of the way posts/users are ranked on many message boards). However there are 2 drawbacks. The first being that I have no idea how to implement that in an automatised way (maybe someone else can help here), but doing it by hand would definitly impossible. The second is that a ranking with stars according to categories would help a lot to make the vetting process more detailed, but it would still have the same basic problem: It would still be people judging builds along their subjective views, therefore necessarily people disagreeing as well. --Xeeron 18:20, 4 September 2006 (CDT)


 * Xeeron: I appreciate your kind comments on my edits. There were a couple more I'd like to reword to better fit native English, but I was hesitant to edit too heavily at once. Since I appear to have your blessing now, I'll do so when time permits.


 * I honestly don't see a good wiki solution for builds, besides total anarchy, which would be basically unusable. I think our current system works well, but I think our current solution is fairly unwiki&mdash;it is essentially a moderation board of ~6 hardcore editors that choose which builds become favored.


 * I think Biro's method is probably the ideal way of doing builds. Unfortunately, that is impossible within the wiki structure, which means it's impossible to host here. Honestly, I think the best solution is to have a sister site that deals exclusively with builds&mdash;the software for Biro's solution wouldn't be hard to whip up from scratch. I'd even be willing to host and implement it, if it meant that GuildWiki no longer hosted builds.


 * &mdash;Tanaric 18:31, 4 September 2006 (CDT)


 * Ooh, a challenge says me! Rating-star-generator proof-of-concept: http://www.t29.dk/~nica/gold.php (Not really useful for anything in practice, unless a seperate box is built that hosts non-wiki code, but I figured it would be fun to do.) --Bishop 15:27, 5 September 2006 (CDT)


 * Just a short note: While there are 2 testers, who do a lot of testing between them (Rapta and Skuld), it would be wrong to speak of 6 hardcore editors. In the last months I have seen many different people vote and even those who voted repeatedly are more numberous. However, even if someone votes on 5 builds, you are likely not to notice him/her unless you check all ~400 builds we currently have. The voting process is really open to everyone, all anon votes count the same as the ones by heavy editors, so I dont see how the lack of participation there is be attributed as the fault of the process. Incidentally, the people participating in the more important process of creating new policies are considerably less numberous than those voting on builds. Does that mean we should scrap all our policies? --Xeeron 07:06, 7 September 2006 (CDT)

Comments on process
I know this has been said in many different places, but I think it's the most relevant here. I think voting is the wrong way to vet builds. I further suggest that build vetting be treated like Featured Articles on Wikipedia. My proposal is not very fleshed out, but briefly: (Below these are the unfavored, archived, etc.)
 * "Featured builds" (currently called "tested builds") are builds that have been rigorously tested by the community and found to be valid and viable.
 * "Untested builds" are builds that have been found to comply with GW:BUILD and satisfies GW:WBE. However, no consensus has emerged that this build is valid and viable.
 * "Build stubs" are builds that are waiting to get into Untested, but currently fail GW:BUILD or GW:WBE.

Now, when someone thinks that they have found a build that is worthy of being featured, he nominates the build for this status and then initiates commentary (i.e., a "vote") on the nomination. The nomination will be a two-edged sword. If the build is found to be exceptional by a supermajority of participants in the discussion (sometimes called "consensus"), it will be made into a Featured build. If the build is found to be terrible by a supermajority, it will be demoted to Unfavored. If no consensus emerges, the nomination (not the build) fails, to be revisited at a later time perhaps. This build will then return to untested.

The nomination will have to come from a non-author. This means that at least one other person must agree with the author that the build is solid and that it satisfies the style guidelines. This will force the author to look for someone willing to nominate the build. I will list myself as an available volunteer for this, and I hope others who care about builds will do so as well.

Why this is better than the current process:
 * There is no feeling that the entire incoming deluge of builds should be taken head on. People can relax and participate in only the nominations they care about.
 * Featured builds will hopefully be of much greater quality as they will have to satisfy style guidelines before they can even be nominated. There will be no premature voting on builds that have huge gaping holes (such as where it is to be used, as I found with A/Me Genjutsu Specialist, a build that was rushed into tested).
 * This will prevent hit-and-run builds, as if an author wants a build to be nominated he will have to put in some effort.

Potential demerits:
 * The untested builds category will be large and potentially unnavigable. This is almost the reality today.
 * Builds can languish in limbo indefinitely.

Comments? zaishen 05:44, 7 September 2006 (CDT)


 * One further note: I am most concerned about the quality of the tested builds, as I think there are pretty serious problems with many of these articles. I think as a class they do not proudly represent the best of GuildWiki. I have started to go over them and clean them up to conform with the style guidelines and the grammar of the English language. Others are welcome to aid this process and if there is enough interest I will make this into a proper volunteer taskforce with centralized coordination (think WikiProjects on Wikipedia). zaishen 05:52, 7 September 2006 (CDT)


 * So its like double voting, but the first voting part is just a normal joe that nominate the build which he things got potential, then the second voting take place where people actually test the build? Not a bad idea. -- [[Image:Ritualist-icon-small.png]] Cwingnam2000 06:04, 7 September 2006 (CDT)


 * I personally dislike the term "voting". The first nomination is not a vote: it's a nomination. Someone who agrees with the author that the build is solid proposes the build as a featured build candidate. Once nominated, the nomination is either supported or opposed, not the build itself. Discussion of the build can take place independently of the nomination. The nomination might have been done too early, before the build has been polished into shape: in this case, the nomination should be rejected, with a possibility of a future renom. Alternatively, the build might have no redeeming value, in which case the nomination discussion might reject the nomination with prejudice and the build will end up in the unfavored gutter. I have three principles here that I think should be kept in mind:
 * Vote on the nomination, not on the build. Disagreements about the build are a matter of discussion, not voting, and should be done on the build's talk page.
 * Votes are not done prematurely. Obviously bad builds can be polished into shape, but once they are dumped into unfavored no one–not even the author–will want to touch the build again.
 * Nomination for featured builds should be centralized. This is like the nominations for administrators. At any time it is absolutely clear which builds are under consideration for featured status.
 * All nominations should time out after 5 days or a week, after which the consensus is tallied. zaishen 07:00, 7 September 2006 (CDT)


 * The build you refer to should not have been made tested, I guess that the anon editing it was not aware of the way we do our vetting. But people doing bad edits is a general wiki problem and not specific to build voting. If anything, with votes clearly displayed, it is much easier to detect such edits.
 * In general, the vote should always about how good the build is, not how good the presentation. Changing grammar, language and formating is an ongoing process in any wiki. Builds should meet certain minimal standards (i.e. not being a stub anymore), but I dont feel that some odd spelling should stop a good build from becomming tested.
 * The drawback of your procedure (as almost any alternative procedure mentioned so far) is its slowness. Imagine we need 1 week to properly discuss a nomination and accept 2/3s of them. After one year, we would have 35 tested builds and some 17 unfavored. On the other hand, we get on average 3 new builds a day (likely the number is even higher). So our categores would look like this:
 * Tested: 35 builds
 * Unfavored: 17 builds
 * Untested: 1043 builds (excellent,good and crap all mixed together)
 * I dont think that would be helpful. --Xeeron 07:06, 7 September 2006 (CDT)


 * I don't think slowness is a valid criticism of this proposal. There is no sword hanging over us to vet builds as fast as possible. In fact, hastiness is the antithesis of filtering for good content. It is far better to have a few well supported builds than a large number of build articles filled with highly questionable junk that somehow sneaked through a premature vote. zaishen 07:23, 7 September 2006 (CDT)


 * "There is no sword hanging over us to vet builds as fast as possible"
 * That really depends on what we want to achieve. If our goal is to filter out the best GW builds, no matter how long it takes, you are right. However my personal goal is different: I try to create the build section that is most helpful for users comming to the wiki. And for that, finding only a tiny number of tested builds is a huge drawback. --Xeeron 07:40, 7 September 2006 (CDT)


 * I don't think having builds of questionable quality in the tested class is being helpful to the reader of the wiki. I also don't think that being hasty about "voting" leads to good results. Lastly, the process I suggest can be as fast or as slow as there are testers available, which is the bottleneck for the current status quo also. However, my proposal will be able to sift for quality much better than the status quo as it will prevent premature votes. zaishen 07:48, 7 September 2006 (CDT)


 * PS: An advantage of the build vote without closing date is that you can continue to vote for tested builds. If some build managed to get through, but enough people feel it is bad and vote accordingly, it will be moved to unfavored. --Xeeron 07:41, 7 September 2006 (CDT)


 * Votes without clear end dates are the worst of all possible ways to go about getting consensus. Consensus can only be built by active participation. It should not be the case that a build is teetering on the edge of some arbitrary figure and months after discussion has died down it suddenly achieves a magic number of votes. Who knows what might have transpired between votes! zaishen 07:48, 7 September 2006 (CDT)


 * IMO, builds voting without ending date is needed, since skills are changing all the time and im expecting them to change more after Nightfall released. If they nerfed or buff a skill, previously tested or unfavoured build maybe not viable or viable respectiviely. -- [[Image:Ritualist-icon-small.png]] Cwingnam2000 08:18, 7 September 2006 (CDT)


 * When conditions change so drastically, it is better to restart the discussion than to have some number of votes from before the change and some number from after. In my proposal, drastic changes can be handled by a renomination for featured status. zaishen 08:22, 7 September 2006 (CDT)


 * The problem is, what makes those votes invalid? as long as they are valid votes, we should accept it. They might not able to vote during the voting period due to holidays or testing extensively ortesting other build. They mgiht bring up points where people aren't aware off by the time of voting or testing, etc. -- [[Image:Ritualist-icon-small.png]] Cwingnam2000 08:29, 7 September 2006 (CDT)


 * Well, no votes in the wiki should be binding. If a build was incorrectly promoted or demoted, it can be brought back to testing and the discussion restarted. Of course, to do this a clear reason must be provided, as we don't simply want to be in livelock. zaishen 08:34, 7 September 2006 (CDT)


 * I prefer this procedure over what we're doing now, I guess. I don't like ease and fluidity of the current procedure's category shuffling and voting.  Like Zaishen, I'd rather it be hard to get into tested rather than easy to get out of untested.  --Fyren 13:51, 7 September 2006 (CDT)

How about this idea... (And please forgive me if it has been introduced earlier in some other format.) How about we add a new category: Category:Builds graveyard or Category:Build fossils. Any build that is unable to escape the "untested" status in more than a month gets moved there. This category is still listed in the "Builds" portal page but with the clear notion that these are builds no one cared to test, try at your own risk. If the build gathers enough votes in time, it is salvaged from the graveyard, if it does not, it languishes there. I would also recommend that the Builds admin (Xeeron in my mind, but he can delegate the delete flagging to others) be given the authority to delete builds in the graveyard he deems to be abolute crap and that he scans new additions to the graveyard once a week or so to make sure the wiki is not gathering junk. It just seems obvious to me that there are builds that will languish in the untested category forever. i.e. Builds that seem to work, but no one cares about them. Think about it build people. --Karlos 07:21, 7 September 2006 (CDT)
 * I don't really see an advantage to having such a category as opposed to leaving it in untested. --Fyren


 * There is one key difference... It says, there is no pressure to test these. The name of the category and the separation is the key. You can say well, people may try the builds in untested at their own peril, that is true. The difference is that for those involved in the Builds vetting process, such a category would relieve them of the pressure of lookingdown 500 untested builds instead of just 50. If a build fails to generate interest among testers or readers for a whole month, then that is just it, it's an abandoned build. If we were paying these build testers, then we would try an dfind a way for them to get through X amount of builds in N number of days without compromising the vetting process. But we are not paying them. 13:51, 7 September 2006 (CDT)

Process proposal initiated
I have started the following, heavily influenced by the featured article system on Wikipedia: These are tagged with as this is only a proposal at the moment. If there is interest, we can attempt to see how it works with a few example builds. zaishen 07:59, 7 September 2006 (CDT)
 * Featured build candidate
 * Featured build criteria


 * I think Mo/E Solo G is a good candidate for this experiment, if the authors are OK with it. zaishen 08:23, 7 September 2006 (CDT)