User:AnticDevices/Thinking

“Hot or Not?” Build Rating Policy Proposal
I propose a rating-based build system. This proposal calls for a Builds:Rating namespace and a Builds:Workshop namespace as the primary areas within the Builds namespace.

Builds: Rating

Any user may submit a build to be rated. A builds ‘rating’ is the average of all ratings. Submitted builds would use the current build style and formatting guide with the following additions: Poorly formatted builds and joke builds will be candidates for deletion. Otherwise, all other builds live on until (a) a year has passed, (b) skill updates drastically alters viability or (c) the build submitter requests otherwise.
 * 1) Date submitted.  This will be a vital tool for organizing builds under this system, as even the best builds become out-dated with skill updates.  If there were a way to automatically tag builds when a skill on the skill bar is updated, that would be ideal.  Barring that, the date submitted will have to do.
 * 2) Rather than putting the voting on the talk page, it would be on the article page.  This is a user-interface concession.  Under this proposal, the ratings provided by the users are as pertinent as the actual build.  The ratings should not be a click away, or otherwise disassociated.  Each user supplies a rating from 0-10.    They may also submit brief comments indicating why they voted the way they did.
 * 3) There is a section where users may propose improvements to a build.  In this way suggested improvements are all in one space, rather than being scattered through the rating comments.

Build Workspace

Here a build creator can submit a proposal for a build. In this space, the creator is soliciting input on the build before submitting it to be rated. Builds in this section are not rated, and it is recognized by the creator that improvement beyond their sole efforts is possible. Effectively, the build workspace does not need to be more than an organized place to announce the existence of a build under development. The actual build can be attached to a user page. Users will not be required to use the Build Workspace or submit it for comment. Build creators will be encouraged at the very least to invite members of the community to double-check the formatting of their build before submitting it to the Build:Rating area, on the principle that ‘with many eyes all bugs are shallow’.

-

Issues:
Technology – there’s no way to automatically collect and average votes on a wiki. Ouch. Yeah. Unless a way to automatically do this can be found, this whole idea sinks. On the other hand, given the number of rating sites on the Internet, clearly it isn’t impossible. But yes, I recognize that someone who has a clue (i.e. not me) will have to step up and provide the essential (scripting/coding/)technology.

Voting doesn’t work! This proposal doesn’t involve voting, it involves polling and rating. No one is being elected. Nothing is being voted off of the island. Rather, a consensus of opinions is being collected.

Rating doesn’t work! I believe that the preponderance of evidence is against this position. The value of using polling as a tool for community concesus is well-established. Further, it is a very popular and familiar tool in Internet communities. There is a reason for this, and I think that that reason is, in part, because it’s effective. Yes, the greatest build ever created isn’t going to have 100 people rate it a ‘10’. And no, the lousiest build ever created isn’t going to have 100 people rate it a ‘0’. But if you look at most polling sites, the items in the top half are generally pretty good, and the items in the bottom half are… well. Less good. Further, as a popular tool, many (if not most) users can easily adapt to using it.

It’s going to be nothing but arguments! Yes, it will. This proposal presupposes that debate is a good thing, and opinions are most valuable when they’re shared. This site describes itself as a guide; this proposal accepts that options and debate can provide valuable guidance. This proposal also presupposes that the reader/rater is responsible for making up their own mind about the value of a build. This proposal rejects the premise that it is the responsibility of the maintainers of GWiki to censor crap builds. Rather, the view expressed here is that it is a player who must assume the risk for using a build they find here. The GWiki is not responsible for whether a build works, only for supplying potentially useful information to the community. Identifying crap builds is of more value to the community than censoring them.

Keeping every freekin build any yahoo submits will take up too much space! Seems unlikely. On this page GuildWiki_talk:Post_No_Builds, Tanaric says "Space is not a concern. This argument doesn't really bother me. If 10000 users end up with parallel complete copies of the build namespace, then we can address this. —Tanaric 23:20, 15 March 2007 (CDT)" Given the pace of skill buffs and nerfs, it seems reasonable to assume that builds that are over a year old can be safely deleted - if the build doesn’t become noticably unviable before then. There are (as of 4/19/07 @ 2:49 pm CST) 166 tested PvP builds and 242 tested PvE builds in the Builds section. Assuming Tanaric wasn’t being rhetorical, that means that there would have to be 4,080,000 builds being rated before he’d worry about it. A more realistic number, say 4,000 builds – 10x the current number – should be no problem. This proposal assumes that Tanaric knows what he’s talking about, and space is not an issue.

This proposal doesn’t prevent duplication! Nope, it doesn’t. Thank goodness space isn’t an issue. There will almost certainly be duplicates and close varients posted. In this proposed ‘poll’ environment, the raters have the opportunity to note similarities and redirect future raters to the original build. This will discourage furture raters from rating the duplicate; as a result, the duplicate will sink and be appropriately disregarded. If duplicates and close variations don’t sink, then clearly there has been found enough value in each to keep both alive. Likely, in this case, the difference is in the way the same build is presented. Different people learn in differnet ways, and different presentations are more effective for some people than others. In the case where multiple instances of the same (or very similar) builds are popular, it is very likely that they are individually popular because they effectively express the same build in different ways. Diversity of presentation is valuable.

This proposal will result in a million NPA violations! Here’s what’s being balanced: Passion vs. censorship. If the Wiki only contains non-controversial information, then you are eliminating the opportunity for a reader to (1) become aware of the controversy and (2) be exposed to arguments by proponents on both sides. I certainly don’t feel that the Wiki should encourage controversy. Equally, I don’t think that the Wiki should limit information based on its degree of controversy. Yes, controversial material is much more likely to invite NPA violations. I don’t think that any build policy – except one that does not allow controversy – is going to get around that. I suggest that the solution - reinforcing NPA as a community standard - has to come from the community, not from the build policy. YAV suggests that all members of the community may contribute; NPA suggests how the contribution should be voiced. Both apply to every page on the Wiki.

So yes, this proposed build policy acknowledges that it will probably create more NPA violations, especially compared to a build policy that presents only non-controversial information. This proposal premises that controversial information has value to the community, and should not be censored from the Wiki. Violators of the NPA, obviously, know what to expect.

This proposal will create a bloated, disorganized mess of a builds section! Two things: Nonetheless, requiring a user to select PvP or PvE from a dropdown, and then Build Type (General, Farming, Running, etc., All) from a dropdown, and then a primary profession (or All) from a dropdown isn’t unreasonably burdensome (assuming it isn’t unreasonably burdensome to implement that functionality on the Wiki to begin with). There will need to be a variety of ways to access & organize builds; admittedly, the presentation of different ways to do the same thing can be confusing to some users. Likely, the solution will be to have a default interface. Regardless, these are solvable user-interface issues, best addressed during testing and implementation.
 * 1) It will require a buff to the search engine, that’s for sure.  Enforcement of the build style and formatting guidelines will be crucial, especially as regards proper tagging.  A main builds section page that allows searching and sorting – which in itself is dependent on technology (programming/scripts) that may not exist – is going to be vital.  Even then, admittedly, the user-interface may still not be better than that of the current build section.  The user will probably have to make several ‘clicks’ before they get to (for example) the top-rated PvE (General) Paragon build.
 * 2) Yes, this build policy does place a greater burden on the individual user for searching and self-organizing than the current build section does.

The builds’ individual rating solves the greater issue of an organizing principle. Somehow the average rating and the number of times the build has been rated will need to be associated with the name of the build. (I have no idea how to accomplish this, but I am confident that a clever coder or scripter can do it.) The rating is really the organizing principle of this proposal, and I believe organizing builds by rating is both effective and an improvement (providing more value to the community) over the current ‘voting’ system.

People will use the rating system as a build development tool, resubmitting tiny variations on the same build until they get a good rating! Ok. Why is that inherently a bad thing? Space isn’t an issue. Crap builds are easily identified by their rating, so no one is tricked into wasting time on them. If a person takes 10 tries to create a good build, everyone wins. The submitter wins, because they finally learned what makes a build good. The community wins, because it now has good build it didn’t have before. All it required was a little time, patience and feedback. These aren’t values at odds with GWiki.

This isn’t better than the Profession Guides! It isn’t meant to be; the two aren’t mutually exclusive. Profession guides are one way of presenting information, most meaningful to one learning style. Builds are another way of presenting information, most meaningful to a different learning style. There is no reason that GWiki can’t have different presentation styles; doing so supports the different capacities of a wider community.

This isn’t better than the NOB policy! Well, the NOB policy has very different premises, it may not be fair to compare. If you disagree with any of the premises that this build policy employs, it can be rejected on that basis alone, the NOB policy doesn’t need to be dragged into it. I will suggest this: The NOB policy and this policy are not as mutually exclusive as they may first appear. If NOB builds are all that and a bag of chips, they will be highly rated under this policy. If NOB builds are highly rated, and original builds are low rated, this very effectively proves the NOB proponent’s point, without endless arguments about whether a build is popular enough to be included in a NOB build section to begin with. The proof will be in the pudding. Regardless, the full spectrum of resources (good and bad, however that is defined) will be available for an individual to make up their own mind about. The individual gets to decide, not the committee that authorizes whether a build is NOB-worthy.

People will vote like idiots! They aren’t voting. They’re rating. Their opinions and reactions are being polled.

People will rate like idiots! Some will. I’m sorry you feel that the preponderance of GWiki users would maliciously or otherwise engage in idiocy. I must respectfully disagree. And again, I believe that the preponderance of evidence is that rating systems are more effective than not. They are not perfect, but I believe this will effectively allow a user to compare a high rated and low rated build and see why one is good and the other bad. Yes, the user has to do some work if they want to learn. I believe that that is the nature of learning; effective build-creation is not handed to them, but it can be inferred with effort. If an individual just wants to grab the highest rated build for a profession, they’ll still have that option, and odds are that build will be reasonably effective.

People will try to get their friends to rate their crap builds highly! I’m sure they will. That’s the fun thing about a polling mechanism. If 10 people rate a build a ‘10’, that build is going to attract a lot of attention. When the wider community sees that it’s a crap build, they’re going to rate it appropriately, and its' rating is going to sink.

I have a great build, and the first 5 raters gave it a ‘0’, and now no one else will look at it! This will happen. Rating isn’t perfect. There will probably be a lot of builds rated 3’s – 6’s that should be lower or higher. The point is that a random user can be pretty certain that a higher rated build with a lot of votes has a high probability of being reasonably effective. Beyond that, caveat emptor. We are talking about an Internet poll, after all. The idea is to create access to the best builds possible without resorting to the lowest common denominator.

'''No, seriously, this sucks! There are 2000 PvE (General) Warrior builds, and my amazing warrior build got rated a ‘0’ by 5 malicious people and now it’s at the end of the list! With only 200 builds on a page, someone has to page and page forever before they get to my build!''' Yes. Some good builds will get lost in the shuffle. This is where it requires some effort on the part of the user to find good, creative and over-looked builds. The up-side of this system is that, assuming that the distribution of ratings across those 2000 PvE (General) Warrior builds runs one would expect, GWiki users are presented with a whole slew of reasonably decent builds on the first page. How awesome is that?

'''Only 20 people really rate builds now! There’s no way this will work if only 20 people bother to rate builds! Their opinions will dominate everything, just like the current system!''' Somehow this seems unlikely, but it could be a real problem if it turns out to be true. ‘Rating’ sites are enormously popular, both in terms of visits and participants. People come out of the woodwork to vote on polls (as evidenced by my participation on the Build Wipe talk page, if nothing else). It seems unlikely that a truly tiny minority of visitors to GWiki will pwn the ratings.

It seems more likely to worry that too many people will be voting at once. The Wiki interface would produce an unreasonable number of ‘edit conflicts’ when a lot of people are rating the same page at the same time. Another item add to the technological wish-list: A way to submit a rating without invoking edit conflicts. Honestly though, I can’t evaluate how likely it is that edit conflicts will occur often enough to seriously impare functionality for a user. I presume edit conflicts don’t bother the server at all; I’m guessing that ‘edit conflicts’ are the output of server error-handling.

'''But people are idiots! They can’t tell a good build from a bad build if their life depended on it!''' We covered this. You have to trust that on aggregate, the community can tell a good build from a bad build, and the good builds will float to the top and the bad builds will sink. It’s not perfect, but I suspect it will work more often than not.

'''Anonymous users can vote as many times as they want! They’ll screw the results!''' Good point. (Well, except the bit about voting. They aren’t voting, dammit, they're rating.)  Upon reflection, you are correct, only logged-in users should be allowed to rate a build. It turns out that that was an unexamined assumption. Hm. This doesn’t seem like it would be an unreasonably burdensome requirement; it seems likely the preponderance of the burden to the community will come with enforcement. If the ‘logged-in’ requirement can be programatically enforced, no problem. Another item to add to the technological wish-list required to make this albatross fly. On the other hand, if this requirement has to be manually enforced, I suspect that that’s a very good reason to reject this proposal.

'''Waaaaaahhhh! It sucks to be inevitably crushed in the powerful coils of your logic!''' Yeah. I get that a lot.