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)

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)