User talk:Gravewit

Epoch to 08/25/2006

Gratuitous Sub-heading -or- Removing admins
I'm really just making this sub-heading because I'm sick of having to scroll up to click "[edit]".

Firstly, have a good trip Gem :) Secondly, I kind of agree Gem. I want to make it clear again that I don't think we should make anyone into an admin unless they can prove that they are rational and open-minded, and that they have good communication skills. But I think you, and most people, agree there, so I won't labour the point! :)

I've been thinking about this in the few minutes since my last post and I think the main reason that I'm not that keen on accepting more admins at present (unless we actually need them, of course) is because we have no real procedure in place for undoing a promotion. If someone decides that I'm not suitable to be an admin... well... what can they do about it? That's not a very defensible position to be in!

If an admin were to be promoted thanks to a community vote (in this case let's say about 5 people) then how would we decide if it was a mistake? Would the admins decide? That could be seen as a conflict of interest, i.e. "Let's get rid of Tanaric because he's obsessed with his case crusade!". And of course decisions made by admins in disputes could be considered unpopular, so would it be fair to let the community judge an admins actions? How many contributors would have to call for his resignation? 5?

I think, if we had procedures in place to demote admins, I would have no problems with making all those people who were nominated and met the criteria admins.  &lt;LordBiro&gt;/&lt;Talk&gt; 03:32, 11 August 2006 (CDT)


 * While I don't know a single case of an admin having done anything that remotely warranted denoting (no, not even you know who ;)), if we should ever need it, the procedure could be simple: Majority vote, as usual. The only problem with this would be sockpuppets. But I think those would be pretty easy to identify in such case.
 * On a side note, I think we should prune the list of sysops and remove inactive admins. I think a long list of sysops may create the false impression of an overly large admin team when infact the number of sysops is somewhat smaller. Of course there is a chance that an admin who has been hibernating for a long time may become active again some day, but in such case they may always get their status back. --[[Image:TurningL sml.gif|Tetris L]] 05:32, 11 August 2006 (CDT)


 * Agree, Mr Skinner, in particular didn't stick around long &mdash; Skuld 06:10, 24 August 2006 (CDT)
 * And I love his block:
 * 09:37, 18 May 2005 Adam.skinner (Talk | contribs) blocked "64.231.153.208 (contribs)" (Special:Contributions/64.231.153.208 (contribs)|contrib) for a duration of 2 years (Vandalism)
 * &mdash; Galil  10:17, 24 August 2006 (CDT)


 * Ohh, and this, also from his logs: deleted Fury (Fury isn't really a topic, it's a rune type related to adrenaline). Now I'm usually not picky, but I do believe admins should atleast know the basics of the game... &mdash; Galil  10:23, 24 August 2006 (CDT)


 * Actually, there were fury runes in the beta. --68.142.14.80 10:49, 24 August 2006 (CDT)


 * In Skinner's defence, the original Guild Wars was released in April 2005, and his involvement here was in mid-May 2005. So nearly everyone on the Wiki at that point was likely fairly new to the game, even those who were in the Beta.  The wiki itself appears to have been first available May 11th, so the wiki was still developing its most basic structures and policies at the time that Skinner was active.
 * But I do agree that admins that have been inactive for a year or more should have their admin abilities removed. I would still list them as inactive on GW:ADMIN, and if they should return at a later point those rights could be re-instated.  But they would no longer show in the counts of Special:Listusers/sysop. --- Barek (talk • contribs) - 10:53, 24 August 2006 (CDT)


 * I also agree with removing the admin tools from people who have been inctive for a long time. But imho even half a year is too inactive. --[[Image:Gem-icon-sm.png]] (talk) 10:58, 24 August 2006 (CDT)


 * Agreed. Either way, I misread the dates in his log. I thought it stated 2006, thus my reaction to "fury runes". &mdash; Galil  11:00, 24 August 2006 (CDT)

ParserFunctions
There's a MediaWiki extension called ParserFunctions that would be useful for us. It's been live on Wikipedia for months now, so it's likely stable. It'll allow us to replace some of the extensive template use we have. This may or may not help with server load, but it won't hurt (the MediaWiki developers don't seem to know either way, but most people like the extension). It'll also allow us to do some interesting things currently not possible or practical, like mostly automatic progression tables in skills or builds showing skill values at the build's actual attributes. Please consider installing this extension. --68.142.14.80 03:59, 24 August 2006 (CDT)


 * I'd like to use the ParserFunctions to replace our current usage of templats such as Template:If-Then and Template:If-Then-Else. - 05:53, 24 August 2006 (CDT)


 * I agree. I've had the very same thought a couple of times. Either way, it would help with server performance, and #expr would help . They're all useful functions. &mdash; Galil  10:08, 24 August 2006 (CDT)


 * Merry christmas! Installed. I'd like someone to give this a good test. Gravewit 15:40, 26 August 2006 (CDT)


 * I've been fiddling with them since yesterday. As far as can be seen from a user perspective, they work as intended.  --Fyren 15:59, 26 August 2006 (CDT)

GuildWiki.org
Any chance of putting a redirect at http://guildwiki.org/wiki/Main_Page ? All my shortcuts are broken, as with other ppl >< &mdash; Skuld 06:12, 24 August 2006 (CDT)
 * See also GuildWiki_talk:Community_Portal, which mentions both this and a second issue that some are seeing. --- Barek (talk • contribs) - 08:43, 24 August 2006 (CDT)


 * Sorry guys. This must've gotten messed up when I upgraded apache. Works again. Gravewit 14:37, 24 August 2006 (CDT)

Database dump
Ping. I sent my mailing address to your GMail account about two weeks ago. Is there a different e-mail address I should use for you? --Fyren 15:59, 26 August 2006 (CDT)

Regarding Incorrect page view bug
I asked in #mediawiki on Freenode about this and someone suggested if it's MW-related, it'd be caused by an external rewrite script. Are you using something like that? I know the (broken, also see the bugs page) navbar you added with links to the other wikis you set up only shows for non-logged in users. Also, there's a bug that prevents non-logged in users from browsing through long categories. They all could be related to such a rewrite script. --Fyren 10:36, 28 August 2006 (CDT)
 * FYI: I went into my user preferences and set the skin to GameWikis (default), which gives the GameWikis navbar at the top - but I couldn't reproduct the linking error listed in bugs (I also logged out, and can no longer get the bug to occur when logged out). --- Barek (talk • contribs) - 10:52, 28 August 2006 (CDT)


 * AFAIK the navbar is not based on whether you are logged in or not Fyren, it's just that Gravewit has changed the default skin after we all signed up. I'd imagine that if you created a new account now then you would also see the navbar as it would be the default skin. I would try this, but I fear that creating a new account would be frowned upon by... certain people ;)


 * Maybe one of the anons who have experienced this problem could try creating an account and seeing if the problem still occurs?  &lt;LordBiro&gt;/&lt;Talk&gt; 11:32, 28 August 2006 (CDT)


 * There's nothing to "see if it still occurs." You get the wrong page if you're not logged in.  If you log in, you get the right page.  Also, as I said, clearing the MediaWiki cache of the page fixes it for non-logged in users, which I did for the two pages that were still acting up (Aeson and Milthraun's Staff).  I checked the MediaWiki cache ID for the pages (which you can get out of the Etag HTTP header or in a comment inside of the HTML for the page) and they matched when I retrieved the page while logged in and not logged in.  This should obviously not be the case since I was seeing a different page for each.  This is why I said "it's very strange" on the bugs page.  MW does not render article content differently depending on the user, so it's something outside of the base MW install.  I don't know if he's using a script like I asked, which is why I asked.  --Fyren 12:07, 28 August 2006 (CDT)

Better caching?
I think the wiki has just the built-in file cache enabled, so have you considered using memcached or squid (or both) instead? I think we're large enough to consider it. --Fyren 06:11, 29 August 2006 (CDT)


 * We use eaccelerator and the built-in caching. Squid would require more servers to get any real benefit, and we can't really afford that right now. Hopefully soon, tho. Gravewit 06:40, 29 August 2006 (CDT)


 * Before you fixed the problem I asked Tanaric to report to you, I took a look at the visible LocalSettings.php. Was that not the one actually being used?  Do you have caching set up somewhere else?  If so, could you show me the MW config being used (minus, you know, database passwords and stuff)?  --Fyren 07:01, 29 August 2006 (CDT)


 * eaccelerator is a PHP module that caches compiled scripts. Instead of the PHP scripts having to be recompiled every time they are requested, the web server can use the already compiled copies. So you wouldn't see it mentioned in the wiki's settings. -- James Sumners 08:16, 29 August 2006 (CDT)


 * Yes, you would. MW can directly make use of squid, memcached, or eAccelerator.  eAccelerator can do more than simply cache compiled PHP.  --Fyren 08:33, 29 August 2006 (CDT)


 * Okay, so I didn't know MediaWiki could take advantage of the shared memory functions. Still, it doesn't HAVE to for eAccelerator to do caching. -- James Sumners 09:19, 29 August 2006 (CDT)


 * Presumably it would do a better job of caching than MW's built-in filesystem cache. --Fyren 09:28, 29 August 2006 (CDT)

I poked around the code and docs some and asked questions in #mediawiki and came up with some more specific info. Running Squid, even if it's on the same server as the wiki, will improve performance as long as the server has enough memory (I don't know where the current bottleneck is for us, but the common database errors suggests it's the database that can't keep up). The file cache only caches pages for anonymous users. Squid would replace MW's built-in file cache and MW can directly interface with it (since the wiki knows when certain pages should be purged, it'll let Squid know). There's a little bit of documentation here on meta about setting it up, if you want to.

Setting up the wiki to directly interface with eAccelerator will help cache more stuff than just compiled copies of the wiki's script, as I mentioned above. Notably, eAccelerator's caching will help with database load. Just set $wgMainCacheType to CACHE_ACCEL to have the wiki use it directly. I think that's all that's needed for eAccelerator since you say it's already installed. The docs say memcached is better for MW's caching, so if you care to install it, that might be even better. I don't about memcached's own resource use.

Also, not really cache related, but it may be helpful to set wgJobRunRate to 0 and have like cron run maintenance/runJobs.php once a day when load is usually lowest. Lots of database updates are queued whenever a high-use template is edited, and lately we've been fiddling with such templates. But, the queued actions aren't vital. WP does the same with their job queue. --Fyren 11:50, 31 August 2006 (CDT)


 * For the record, a SourceForge engineer sent me a detailed document about memcached, which I forwarded to Gravewit. As I know nothing about caching technologies and their various implementations, I won't say any more about this. &mdash;Tanaric 12:40, 31 August 2006 (CDT)


 * I agree with Fyren. We should set wgJobRunRate to 0, or a very low number to greatly increase performance. As seen on MediaWiki's own description of the variable, it's easy to tell what kind of an impact this has on the server. If it runs one job each request that means it runs at least 200 jobs per second (note that request isn't only referring to pages, it's also css files, images, javascript, etc) since the wiki currently has about 20 pageviews per second and there's usually at least 10 requests per pageview. Setting wgJobRunRate to 0.01 or even 0.001 would allow about 2 jobs per second or 1 job every 5th second and should greatly increase performance. &mdash; Galil  15:07, 31 August 2006 (CDT)


 * eAccelerator is running and it's stats say it's caching things like it should. I tried setting the stuff in LocalSettings.php but it sent the server load to 100+. It usually sits at 4-10. Gravewit 23:10, 1 September 2006 (CDT)


 * I'm not sure if eAccelerator itself should be configured in a certain way. The documentation on MW's caching is pretty much non-existant and the advice from an actual MW dev in #mediawiki when I asked when memcached/eAccelerator should be considered was just "if the wiki is slow, try memcached."  Did you check which process(es) were causing the load to spike?  Did you change anything in LocalSettings.php besides the cache type at the same time?  --Fyren 23:28, 1 September 2006 (CDT)


 * Thanks for setting wgJobRunRate to a lower value. This is much better. :) &mdash; Galil  22:27, 4 September 2006 (CDT)

Is there a strength switch? I keep editing stuff anf having to purge to see what I wrote >< &mdash; Skuld 07:10, 2 September 2006 (CDT)
 * The wiki always knows when something is out of date and should purge the cache itself. I haven't had any problems like that, though.  (Just tested an edit now in the sandbox to be sure, too.)  Does your ISP force you through a proxy, maybe?  --Fyren 07:38, 2 September 2006 (CDT)

GW gold ads
I just noticed yet another GW gold add in the google sidebar banner. We still haven't managed to get rid of them??!! I don't have to remind you of the fansite requirements, do I? "Members of the Guild Wars Community Fansite Program webmasters and all site staff members agree to the following: [...] To disallow and remove links or promotion of [...] sites that support, advertise or offer in-game items for real currency". Please, do something! -- 13:05, 30 August 2006 (CDT)


 * There is absolutely nothing I can do beside tell google about it, which I've done over and over again. Gravewit 16:27, 30 August 2006 (CDT)


 * I think the problem is not ours but google ads -- [[Image:Ritualist-icon-small.png]] Cwingnam2000 16:31, 30 August 2006 (CDT)

Bot
Could you flag Fyrenbot as a bot? I'm going to run it over the skills to unstub all the ones that shouldn't be stubbed (which seem to be a lot out of the 300). --Fyren 23:04, 1 September 2006 (CDT)

Request: Close the GWG forums
Could we please close the GWG forums and change the Navbar link to our own GameWikis forums? We've reached the point now where I believe we can sustain our own forum system. I believe it's confusing to users to have two seperate, mostly inactive sets of forums. &mdash;Tanaric 18:32, 7 September 2006 (CDT)


 * I would like to say I agree with Tanaric regarding this issue. Not only would it combine the traffic of two rarely used forums it would also give some additional press to GuildWiki's sister wikis. Main reason being the nav bar does not appear on some skins (I use Cologne Blue), and I find it more comfortable to use than the traditional skin. So some users may not be aware of other new wikis that are growing, such as HammerWiki and NeverWiki, for which they may wish to be apart of. -Gares 07:07, 11 September 2006 (CDT)

More GW gold ads
It seems that everytime Google finally takes action, the advertisers just register a new domain. So, here are more to report ... Skryer.com - gameim.com - pglap.com - vir4s.com - iGameTrade.com - gwgamegold.com When signing up for Google ads, are there ad types that you sign up to receive? If so, and if we are currently signed up for a pc gaming category, then it may be time to look at alternate categories. Or, barring that, time to see if another ad service besides Google could be used. --- Barek (talk • contribs) - 15:05, 18 September 2006 (CDT)


 * From my understanding, Google ads claim to find 'info' from the page and generate a list of possible related ads and display them. So, if these page suddenly contain 99% of lets say, Watches information, we might get some Rolex Ads. -- [[Image:Ritualist-icon-small.png]] Cwingnam2000 15:15, 18 September 2006 (CDT)


 * Google ads decides which ads to show by reading through the page text and deciding which ads seem to fit in with the content. My user page for example sometimes shows jewllery ads. ;) --[[Image:Gem-icon-sm.png]] (talk) 16:31, 18 September 2006 (CDT)


 * Hmm, wondering what they display on my page, since i removed the ads. -- [[Image:Ritualist-icon-small.png]] Cwingnam2000 16:37, 18 September 2006 (CDT)

Time to deal with open proxies...
Ok... We've had problems with Deldda Kcarc before and now this FG guy. Both boast of their ability to keep harrassing the wiki through open proxies and the like. I would like to ask that we adop such a policy as Wikipedia:WP:NOP. Can you assisst in this matter? --Karlos 14:02, 19 September 2006 (CDT)
 * I like this idea; but I'm concerned about implementation.
 * From an administrative standpoint, I'm not sure we have the resources to accomplish this. It appears that the open proxy blocks on WikiPedia are manually maintained.  I didn't see notes of automation nor of a system solution for this.
 * The link you provided references Wikipedia:WikiProject on open proxies. It appears that their method is to manually identify open proxies, block them manually, then submit all that they block to the Wiki Media Meta Project so that all of their associated sites can share the "to block" list and they track a blacklist of IPs that are not yet blocked on all of their sites.  Last, once blocked by all sites, they log the IP in a category showing it blocked on all related sites (currently looks to be roughly 5000 IPs).
 * The problem that I see is just trying to keep current on which IPs are blocked, as some are always being added and sometimes even removed from the block list. Unless it can be automated in some way via a bot, I really don't see a practical means by which we could keep ahead of this. --- Barek (talk • contribs) - 14:34, 19 September 2006 (CDT)


 * Can't we just borrow their list? Share it, re-use it, whatever? --Karlos 14:38, 19 September 2006 (CDT)
 * I'm sure we could; but it appears to be a manual process (or at least only documented as a manual process) on WikiPedia currently. Unless it can be automated, I don't see how we could hope to keep current with their list.  There will always be new IPs being added, which we would need to monitor and block ourselves, and some being removed when they fix their configuration to no longer be an open proxy (or when the offending system changes IPs and a new innocent machine gets the blocked IP).  If it can be automated, then great.  Hopefully Gravewit can assist with that.  But if not, it'll be difficult to keep up manually. --- Barek (talk • contribs) - 14:46, 19 September 2006 (CDT)


 * For clarification and curisity, when/where did Deldda Kcarc actually boast his ability to keep harrassing the wiki through open proxies and the like? The only bad thing I ever remember from him was "I wish this wiki the worst", or something vague like that.  F G is the only one I actually remember of with harassment.  Of course back then discussion was going on all over the place, so I might simply have not caught notice of things instead of not remembering them. - 14:51, 19 September 2006 (CDT)


 * When I banned him, he made some other IPS and kept clearing the page and I kept banning them, then finally made the mock edit to the policy page. You were right in the middle of it when you were helping revert his edits and then you discovered he was banned. --Karlos 19:56, 19 September 2006 (CDT)


 * Ah, I didn't realize those were related to teh open proxies at all. - 21:45, 19 September 2006 (CDT)


 * I don't see any point in banning open proxies. It's not going to stop a really determined user anyway which this person is. There are reasons to use an anonymity network, I used to use one to get around the content blocker here at work. Tor and co are very slow though, if you wanted to go on a vandalism spree you wouldn't use onion routing. Really we're talking about one user here that occasionally posts stuff on a talk page that only a few old timers read, who cares? Is it really worth going to the trouble of implementing a open proxies banlist and denying a bunch of potential good contributors? Isn't the person in question just winning then, they disrupt the wiki, prevent valid edits and in all honesty can probably still make edits with relative ease. --Xasxas256 17:40, 19 September 2006 (CDT)


 * Well, it's an interesting dynamic, because on the one side, I agree with Wikipedia that the overwhelming majority of people using them are doing so for bad reasons. On the other side, being a game site (not a "respected" site like Wikipedia is now) we will face being blocked by more firewalls at people's jobs. So, the percentages are adjusted. However, I think it will help deter people. --Karlos 19:56, 19 September 2006 (CDT)


 * As I understand it there's one person who's probably using an open proxy to harm (although it's not even direct vandalism, it's just trolling) the GuildWiki. A knee jerk reaction in my opinion that is somewhat complicated to implement and won't even help things much. I still don't see the benefits, "Time to deal with open proxies..." makes it sound like we're having some kind of major issue with vandalism via open proxies, I don't think we are at all, we are just perhaps having some minor problems with a single user. --Xasxas256 20:24, 19 September 2006 (CDT)


 * There is nothing knee-jerk here, Xasxas. You were around when the whole Stabber drama was going on and blocking proxies was pretty much agreed upon by all involved. The question was always a question of effort, not doubting that we should even do it. This is not "one guy" though. There is Deldda, there were a few incidents before where a vandal kept coming back a number of times. It just troubles me personally, that people with a certain level of computer aptitude come to our wiki knowing they are "above the law." I know that those who are good will find ways still. But at least, let's keep an honest defense against such power trips. --Karlos 20:32, 19 September 2006 (CDT)


 * From what I remember (and it was a while ago, my memory may not serve me correctly) it was F G who was pushing for the blocking of Tor IPs, I don't remember it being agreed apon by the community. Although "pretty much all involved" may just refer Stabber and F G in which case your statement is correct but it should be decided upon by the community.


 * Yes the Stabber thing was a major drama but only because it was made so personal, using open proxies had little to do with the overall controversy. I still don't think that blocking open proxies is going to offer much benefit to the GuildWiki. Sure no user should be "above the law" but then again our admins shouldn't squash the little guys in a quest to go after a high profile crook. --Xasxas256 21:18, 19 September 2006 (CDT)


 * User:Xasxas256 is right about the ineffectiveness of this proposal. Blocking open proxies is an uphill battle and in the end people who really want to can find a way to get past any blocks. The "honest defense" you propose is paper thin. Also, Karlos, you aren't the law. My fight isn't with you, but you keep setting yourself up as my enemy. And regarding the nature of the drama, my recollection is very different. I seem to recall that Stabber's actions were almost unanimously censured by the community. I seem to recall that sock puppetry was nearly unanimously declared unacceptable by the community. I am not responsible for Stabber's conduct! Lots of people would be and are interested to know if a user is a Stabber sock. See this for example. I am a late arrival to recent events anyhow as others had fingered the socks already. This paranoia is not my doing, though I commend it. 64.78.164.226 21:37, 19 September 2006 (CDT)


 * For the record, my recollection greatly disagreed with the anon above. The biggest drama has always been F G making a big deal out of Stabber's insignificant drama as well as making accusations which, even if they are true, did not constitute disruption of the wiki in my book, so there's no reason for me to care (about the validity of the accusations).  A few people were vocally calling for sockpuppetry to be unacceptable, MANY were silent or wait to see HOW sockpuppetry is going to be defined/determined before commenting.  And eventually it just went nowhere.  At least that's how I felt. - 21:51, 19 September 2006 (CDT)

Just FYI, the old debate is mostly here. --Xeeron 04:49, 20 September 2006 (CDT)


 * For the record, although my opinions have been long stated on the subject, I don't have anything against sockpuppetry unless the user carries out vandalism or affects consensus. I think, if Stabber was sockpuppeting, she had a valid reason for doing so; she had accrued quite a bad reputation (undeserved in my opinion, she was a pain in the ass and unnecessarily confrontational at times, but she was a good contributor with a sense of humour). Those accounts accused of being her sockpuppets have all just been... well... pains in the ass and nothing more. As far as I'm aware, none of those accounts have either been 1. proven to belong to her or 2. done any harm at all to the wiki. What's the big deal?


 * As for blocking open proxies, I don't agree with it. Dealing with people who are annoying and using an open proxy is sometimes frustrating, but equally (as far as I'm aware) using TOR or the like makes it very difficult to carry out any mass vandalism, so it's not a great concern of mine. If we ever did have an instance of mass vandalism from open proxies then I would feel more inclined to support this action.  &lt;LordBiro&gt;/&lt;Talk&gt; 05:32, 20 September 2006 (CDT)


 * Very well. I withdraw my request then. There is not enough support for it and I won't bother build any support for it. :) My recollection was that everyone (including Stabber, and the other random people who kept popping in to cite wikipedia policy and advising us on the matter out of the blue) were on the same page that this should be done. I thought the issue died in defining what is sockpuppetry and what is harmful sockpuppetry and what, if anything, should be done about it. So, never mind. :) --Karlos 19:35, 20 September 2006 (CDT)


 * I should've spoken up more - I support the concept of blocking open proxies; I just see the implementation to be problematic. If the issues I mentioned could be overcome, then I could be convinced to support this. --- Barek (talk • contribs) - 19:45, 20 September 2006 (CDT)

Search engine
In includes/SearchEngine.php, the function getNearMatch tries some heuristics before attempting to do an actual text search. It takes the text given and converts it to all uppercase, all lowercase, and first letters of words uppercase to see if article title matches exist. I could pretty easily change it to try first letters uppercased besides words like "the," "of," "and," and so on. I'm not sure if this would overall help or hurt searching, but someone with shell access could figure that out since you seem to not like replying to me very much. --Fyren 14:55, 27 September 2006 (CDT)


 * I whipped a quick snippet to do this (that might not play well with UTF-8, not that we have non-ASCII content). An alternative is to law down the law over on GW:REDIRECT's talk page.  Galil argued from the performance standpoint already but no one seemed interested.  The policy right now says no redirects from plurals or all lowercase, which increases full text searches by not allowing the existing heuristics to find an all-lowercase or plural redirect.  --Fyren 13:32, 29 September 2006 (CDT)


 * Fyren, I raised the point on GuildWiki_talk:Redirect that bandwidth will not be adversely affected by a reasonable amount of redirects (not sure if that's what you're referring to above) and there was very little opposition to it. Even Tanaric, who was strongly in favour of the policy as it stands, conceded that there was probably at most a very small impact on performance. I'm not sure if this helps!  &lt;LordBiro&gt;/&lt;Talk&gt; 13:43, 29 September 2006 (CDT)


 * This doesn't have to do with bandwidth. If someone searches for "signet of judgment" it falls back on a full text search since there's no article/redirect to be found at "Signet of judgment," "Signet Of Judgment," or "SIGNET OF JUDGMENT."  When a redirect isn't used, there is no performance cost due to the redirect just existing.  Searching the wiki text is probably an expensive operation, since it ends up going through the text for the entire wiki, even with the benefit of search indices.  If a redirect is used instead of a text search, there is likely a very large (relative to a text search, at least) performance benefit.  The alternative to redirects is patching the code as I suggested, which means a slight additional cost per-search that would normally fall through to a text search yet still not match an article.  But, when the new heuristic (which would try "Signet of Judgment" where the existing ones don't) it would definitely help.  It kind of depends on the ratio of searches this will help versus those it doesn't.  The relative costs of not uppercasing a few letters compared to a text search are very different, so if this helps even 1 in 100 searches, this would probably be a good idea.  Of course, redirects would help no matter what the ratio is.  --Fyren 13:58, 29 September 2006 (CDT)


 * Consensus on GW:REDIRECT appeared to be to allow search-assistive redirects. Even I'm in favor of this. Fyren, since you seem the most well-versed in this subject, would you mind making the change in the policy article? &mdash;&mdash;Tanaric 14:54, 29 September 2006 (CDT)


 * Well, it would be a near complete reversal of the policy. Plurals, various conjugations, and all-lowercase redirects will all help searches.  --Fyren 14:58, 29 September 2006 (CDT)
 * Based on the other comments that I saw, it appears that we only need one case redirect - just standardize on the one case redirect is all lowercase, all uppercase, or all first letter upper case. The heuristics match would catch on that single redirect, solving the problems.
 * On plurals, I remain against them just on prncipal that the encourage sloppy linking to go through redirects; and because I think it should be relatively minor to modify the heuristics to recognise if the terms ends in an "S", to try matches without the s. In that case, the only redirects for plurals needed for search purposes would be if the plural is a change in spelling (ruby vs rubies, etc).
 * At worse, even if we do allow redirects for plurals, the policy should only be modified to allow two redirects for these types - one singular and one plural, and both in a format that will get caught by the heuristics match. No need for every possible combination of caps/plural to be allowed. --- Barek (talk • contribs) - 15:59, 29 September 2006 (CDT)


 * Well, bandwidth is certainly involved in the equation. If someone does a search for "Signet Of Judgment" then we have to send the search result and then we have to send the actual article, Signet of Judgment. That's twice the bandwidth we would use if someone were just taken directly to Signet of Judgment; it would halve the amount of HTML we had to pass to the client. Of course the performance hit on the SQL server is probably a bigger concern.


 * The reason I posted the link to the redirect talk page was because there seemed to be consensus there that using redirects to aid searching was acceptable.


 * So yeah... I don't see what we are disagreeing on really. You're saying pretty much what I said on GuildWiki_talk:Redirects, aren't you...? :P Sorry if I'm missing something...


 * And, further to that, any heuristics that could be added to the text-search function sound like a good idea to me.  &lt;LordBiro&gt;/&lt;Talk&gt; 17:01, 29 September 2006 (CDT)