Talk: Community portal/Archive 10

State of the Wiki: Builds

I argue that as an encyclopedic reference to Guild Wars not including popular builds would be very narrow-sighted.

Now how this would be done is pretty tricky. Shandy 07:11, 18 November 2005 (UTC)

That was one of the first answers I got when I started talking about builds on the wiki. And Shandy was right, including builds has worked out, but it is tricky indeed. So for all those who are not involved in the builds process (but often see lots of build related pages spamming recent changes), let me give you a quick overview what the build section currently does, why there was a lot of talk about it in the last months, what is not running smooth and why adding builds to the wiki is still a great thing.

History

The wiki was founded by a crowd of PvE lovers, so after the first months, there was decent coverage of most PvE aspects of the game, but the builds section was almost entirely consisting of the pre-builds, plus several weird concept builds. To sort out those of them worth keeping, a build vetting process was introduces. Later, when people started to post more new builds as well, that evolved into the voting, which is more or less in the same form still in use.

The new section drew some attention from those who possess superior (to mine) wiki skills, so soon we got nice templates, ordered [:Category:Builds|categories] and a beautiful builds portal. Unfortunatly, as the number of people working on the wiki to test builds grew, the number of new builds exploded. That lead to several attempts to streamline, change or speed up the process of build vetting, most of which did not have a big impact.

Right now, a refined version of the basic voting vetting is still in place, I tried to write that (and all other relevant stuff about builds) down here.

The basic problem with builds

The basic problem with builds (and reason behind 95% of all troubles related to builds) is the nature of builds as subjective articles. Unless almost all other aspects of the wiki, the quality of a build can not be objectively measured. That means, if there is to be any skale among builds, it will be a subjective one. That of course can give rise to many conflicts: Either if people disagree about builds, and, maybe even harder to solve, there is a conflict about the correct mechanism of how to take lots of subjective opinions and synthesize them into one wiki article. The later lead to long discussions about a build policy, without any consensus reached yet, meaning the wiki currently does not have any build policy.

Why are builds on the wiki still a great idea

Despite the frustration which can arise about all the conflicts related to builds, this should not distract from one fact: The users love them! The build portal currently gets around 15.000 views per day, making it the 5th most popular page of the wiki. The guildwiki has proven that builds do not only belong on forums, but that the wiki concept can be used to provide simple and easy access to build ideas to all users. The builds section has also helped to attract many new users to the wiki, especially from the previously hardly represented PvP part of the community.

Let me put in 2 maybe somewhat specific lessons that can drawn from the builds part of guildwiki:

• Templates and nice structure works, even for new users, as long as the user side is kept simple. There is possibly no template in the wiki which is more successful than Template:Skill bar. I have seen literally hundreds of new build articles, done by first time users, and more than 99% of them understood and correctly used the template (and the later attribute template as well) for their first build. As long as there is a page describing their use and the template keeps using plain text on the part the user sees, they do work, making articles much nicer to read.
• Users like portal pages. The builds portal consists to 80% of just a listing of [:Category:Builds], yet after it was introduced, the number of pageviews skyrocketed. New users unfamiliar with the workings of a wiki will have a hard time if they hit a link on the main page and are dumped in a category with a one line description. The best information is not good enough, if users cant find it. Some other parts have great portal articles as well (for example the green weapons lists), but there are still several links on the main page which lead to ugly categories. Some beautification of these links would maybe be one of the simplest ways to enhance user value in the wiki.

So in the end, builds on the wiki work, not without some problems and effortless, but the result proves that the effort is well invested. --Xeeron 10:46, 6 October 2006 (CDT)

Discussion

It would be such a shame to break up the above with comments, so I'll put mine here instead :) This is a good summary for anyone unfamiliar with the Builds section of the wiki who is interested in learning about the recent discussions. Good work Xeeron! You've kept it pretty objective, so I don't have any problems with it.

It is certainly true that portals in general are generally well received, and for some time I've been an advocate of creating articles to compliment the current category setup that we have on the wiki.

Anyway, good work Xeeron! <- for you. <LordBiro>/<Talk> 11:34, 6 October 2006 (CDT)

I am continually amazed by you Builds people. :) ——Tanaric 02:17, 7 October 2006 (CDT)

I think the whole builds section of GuildWiki is a huge mess, and a nuisance. We created a wild monster that is growing by the hour. But since feeding the monster is very popular it doesn't look like it's going to be killed anytime soon, so I'll have to live with it. ;) As a personal solution I decided to ignore the complete namespace alltogether. My main problem is that I can't filter out both the Build: namespace and the Build talk: namespace from recent changes at the same time, only one at a time. If anybody knows a way to do that, please leave a note on my talk page. -- 06:08, 4 January 2007 (CST)

And the above is one opnion worth mentioning. The other side, which i support, is that restricting the builds section elitism and that wikis and the gw game were both founded on creative thiking. Another issue you should mention is the fact that many, from both sides of the builds debate, feel the vetting process sucks and needs reforming.--TheDrifter 21:14, 5 January 2007 (CST)

Mirror

Take a look at this and [http://erkdog.netho.tk/gw-wiki/gw.gamewikis.org/wiki/Main_Page.html this]. I think it is a great idea as a backup whenever th wiki is slow or down, but it would be great if it could somehow be institutionalised so that guy down not have to use a DL program to get the wiki pages. --Xeeron 06:41, 6 November 2006 (CST)

Yeah, I outlined what is required to provide an effective and complete mirror. Basically all I would need is access to a snapshot the PHP / images and an almost complete SQL dump.

Perhaps Fryen would be willing to provide this? If nothing else it would be a stopgap measure until new hardware was in place, and instantly provide a complete mirror. You could put a temporary link at the top of the page to indicate if people are going to be reading the Wiki only to my server.

However, I think it would behoove GuildWiki to strongly consider setting up the infrastructure required to provide permanent mirrors. Fryen, I would be happy to discuss this with you in detail as to what is required to keep a regularly updated Mirror online. It can easily be done without creating significant load on the site's servers. I guarantee you that my mirror software continuously crawling the site generates more resource use than providing a daily snapshot of the PHP / IMG and salient SQL tables.

The database dumps can be tailored to the point that they are not large. The main content of the articles would be the only thing necessary for a mirror.

History is not necessary. Incremental updates to the database can also be created via binlogs.

Not to mention the fact that after 4 days of crawling I still am nowhere near a complete mirror.

If nothing else, a complete DB Dump and PHP / IMG snapshot could be provided so I could create a complete mirror in the interim while you wait for new hardware.

If the information I requested above in the server section was provided I could also provide some insight into the slowness and make suggestions on configuration that would speed things up as well. ErkDog 11:53, 6 November 2006 (CST)

Gravewit had apparently already wanted to figure out how to get dumps out to people but not made an effort (possibly due to concerns about bandwidth). Dumps of the current article revisions are easy to make (and small) but I'm not sure if we even want to attempt to provide our images as an "open" download since even only the current versions total 1.3 gigs. I will get something regular going for at least article dumps but only at some point after the new hardware is around. --Fyren 23:48, 12 November 2006 (CST)

Fyren, A compressed version of the PHP and IMGs would be nowhere NEAR 1.3 Gigs. Additionally you would not have to provide the mirror content "publicly." Assuming the database and images themselves were even as large as 2 Gigs (Which they are not.) That should be insignificant toward your monthly transfer limit. If it is not, perhaps you should consider an alternative hosting provider. Although the size of the data is irrelevant if you only allow mirror peers to access it. Rar should turn about 1.3 Gigs of images into a few hundred megs at most. Also, there are HUNDREDS of places you can put the dumps that provide free download. RapidShare, File Planet, Planet Miror, just to name a few. You of all people should know this being a server administrator. You should also know that even gunzip would squish the hell out of those images, much less a sophisticated archiver such as rar. ErkDog 07:06, 13 November 2006 (CST)

Firstly, I'm not a server admin.

"You should also know that even gunzip would squish the hell out of those images, much less a sophisticated archiver such as rar." On the subject of image compression I think you will be hard pushed to find any algorithm that will compress 1.3 gigs of predominantly JPEGs into an archive weighing in anywhere below 1 gigabyte.

As far as I'm aware, common lossless compression algorithms (including RAR) build a table of repetitive patterns of bytes in the input and replace those repetitive patterns with shorter patterns. The most commonly recurring patterns in the input are replaced by shorter patterns in the output. JPEGs are reduced in size using a lossy algorithm, and then further reduced in size using this lossless algorithm. Therefore there are very few repeating patterns in JPEGs and therefore less to compress, so to speak.

The more JPEGs you try to compress the greater the level of compression you will (typically) be able to achieve, since more JPEGs equals a greater chance of repetition. Bearing this in mind I just carried out a test, compressing 1.82 GB of JPEGs that I happened to have at my disposal using WinRAR's "best" compression option. I managed to produce an archive of 1.71 GB.

I used 1,184 JPEGs, so some basic maths tells me that they average at about 1.57 MB each. I presume that the average size of images on the GuildWiki will be smaller than this, so I would imagine the images from the GuildWiki would compress better than my images. If the GuildWiki images did compress at the same ratio as mine then they would produce a RAR weighing in at about 1.22 GB.

I am by no means an expert on compression algorithms, so if my information here is incorrect please let me know. <LordBiro>/<Talk> 18:43, 13 November 2006 (CST)

Just as a data point, the bzip2'd compressed database, for the current wikipedia articles, is around 1.6GB (you can see this by going to the wikipedia database download pages -- yes, unlike guildwiki, the much larger wikipedia does allow database downloads!). As this wikipedia dump has over 1.4 million articles, I think it's safe to say that a compressed guildwiki dump would be much smaller. Reference: http://en.wikipedia.org/wiki/Wikipedia:Download And, given that there are probably a number of places who'd be willing to host periodic guildwiki current page dumps, I don't think bandwidth is really an issue. Frankly, I've love to have an offline-accessible guildwiki setup (xampp and others are your friends). 21:37, 13 November 2006 (MST)

I did say a dump of the article text would be small. You'll also note that the Wikimedia foundation has just a few more servers and a little more resources in general than us. --Fyren 23:14, 13 November 2006 (CST)

As Fyren said, he did say that a zipped version of the articles would be small, and of course I didn't say anything otherwise in my post. And just to demonstrate the difference in size and capacity between GuildWiki with its 2 servers and MediaWiki with its... well... several hundred servers, please see this pic. <LordBiro>/<Talk> 04:17, 14 November 2006 (CST)

Yeah I forgot JPGs can't be significantly "squished" but the fact remains, assuming the salient database data and PHP / JPG data are as large as 2 Gigs (Which they would not be) it would NOT create significant pressure to create backups and allow mirror peers to download them. When you consider the fact that the mirror content can be offloaded to an entirely different place the size utterly becomes a moot point. Then when you consider the fact that thousands of db queries and http requests would be offloaded to the mirrors, the relatively tiny amount of resources required to create a backup and provide it to mirror peers FAR outweighs the few resources required to create and distribute the mirrorable content. We should stop discussing whether or not you have the resources to supply mirrors. It would be painfully clear to a retarded tree frog that mirrors make sense. What we need to do now is discuss a way to make it happen:

1) Create a script to dump the database with the exception of the user table and some of the more frivilous data. 2) Create a script to compress the img content into an archive. 3) Create a script to compress the PHP content with the exception of config.php or any other files which contain GW's actual DB credentials. 4) Create an HTTP folder which is protected by an .htaccess file to only allow download from specific IPs.

On the mirror end.

1) Create a script to grab the dumps on a regular basis 2) Wipe and import the new database. 3) Uncompress the IMG and PHP archives.

Viola mirror.

Fyren, let me know if you need help creating the scripts or .htaccess file above.

Thanks, ErkDog 07:44, 14 November 2006 (CST)

Fyren, I just had an epiphany. Something that would be completely transparent to gamewikis and require little to no work on your end. Squid (or another cache). Instead of people setting up mirrors of the actual content. People could donate Squid (or another cache) processes.

This could be done completely transparant of the existing servers and setup. Basically what we would do is come up with a good squid (or another cache) that obviously listens on port 80. We setup another DNS (squid.gw.gamewikis.org) for instance, which would be an RR DNS to all available squid caches. And viola. Anybody using that host hits the squid servers and potentially avoids a query to the main Guild Wiki server entirely.

Down the road it could be modified such that something monitored the status of the configure cache servers and (as appropriate) deleted or added their DNS records to remove down caches from the RR DNS.

I have a bit of experience with Squid but am certainly not a Squid master. I know if nothing else, this will definitely cache image requests. It may be necessary to remove the counter at the bottom of -every- page. Something that should have been done already anyway considering the excessive load the site is under at the moment. That's an extra data base query and update on every page load. Eliminating that Update on EVERY page load should save a few cpu cycles and I/O definitely.

Let me know what you think. ErkDog 10:49, 14 November 2006 (CST)

We're already running a local squid and having (only) more squids elsewhere won't help the problem of apache/MW load besides that (at best) we could not run squid here. Once whatever the hell is happening with the new machine gets sorted out, we'll have squid on its own machine and squids elsewhere won't help besides for bandwidth.

Also, with "remote" squids, a cache miss would mean things will be even slower for users as squid ends up going to our apache. You'd ideally want an apache server local to the squid... and then you'd also want a local DB slave/mirror... and maybe memcached (making it a 2-3 machine setup, even if those machines aren't dedicated to us). It's a lot to ask for on top of bandwidth. I'd also be generally apprehensive about trusting machines in someone elses' care, but that's a separate issue.

About the page view counts, I had disabled them briefly to gauge the effect. It made no apparent difference. --Fyren 19:54, 14 November 2006 (CST)

Memcached would help more than Squid does. As for remote squids, any thing that can be served by the squid is 100% load relieved from your Apache / Mysql. Memcached can also be run on the same box as apache. Memcached is designed more to relieve MySQL Load though. And according to you it's HTTPD Load not MySQL that needs to be relieved. If you don't disable the page counters then Squid can't really do it's job. Every page load is different and it can't cache any of them. The reason you didn't notice a difference is because the load is so ridiculously high it made a relatively inconsequential difference. But you are preventing squid from doing it's job by not leaving it on. Futhermore, it is DEFINITELY an update on ever page load. ALWAYS. You should turn it off. It's frivilous information, breaks squid, and increases I/O load a great deal. ErkDog 21:16, 14 November 2006 (CST)

It doesn't break squid unless by "break" you mean "users seeing a cached page will see a cached number." Incrementing the count when a request goes through to apache doesn't cause squid to purge the page from its cache. --Fyren 21:30, 14 November 2006 (CST)

Well, I guess it would depend on how you have squid configured, if it's configured to IGNORE IMS then yes it won't matter. But it also won't pick up LEGITIMATE changes either. Look at the hit % it can't be that great if you don't have Ignore IMS and w/o disabling that and counter ErkDog 22:28, 14 November 2006 (CST)

MW tells squid to purge pages when appriopriate. MW knows when a page is edited/a file is uploaded/whatever. --Fyren 23:15, 14 November 2006 (CST)

O M G whatever, I'm done trying to help with this crap. Squid has no way for external programs to notify it when it should expire pages. Squid operates off IMS or a hard timeout depending on how you have it configured. MW cannot tell Squid to expire a page. Fyren > * good luck. I'll stick to updating then Wiki when it bothers to be responsive enough for me to do so. ErkDog 23:19, 14 November 2006 (CST)

Don't let the door hit you on the way out. --Fyren 23:37, 14 November 2006 (CST)

Fyren, he was just trying to help. No need to rub it in and alienate him. :( ErkDog, I appreciate your attempt to help, but I'm also confident that our server is in very good hands with Fyren. We'll see if the new server hardware gets our performance back to normal. I take it, if GWiki still runs sluggish after the server upgrade, we'll reconsider mirror options. -- 02:22, 15 November 2006 (CST)

To be honest, Tetris, Fyren didn't say anything unreasonable until after ErkDog had thrown a tantrum. I wish Fyren hadn't just said that, but I still don't think he was in the wrong. It's a very stressful time at the moment for Fyren, having to mediate between an angry wiki and Gravewit. I know ErkDog is/was only trying to help, but Fyren has not criticised any of ErkDog's suggestions, he's only explained why certain suggestions would not work, and what he is capable of doing.

Fyren might not have all the answers, but from my conversations with him I'm confident he knows a lot about MediaWiki and the technologies surrounding it. <LordBiro>/<Talk> 03:00, 15 November 2006 (CST)

It was kinda nice to see some discussion unfold really, talking it out is good not just for drinking problems but wiki problems too. Anyway it's a shame ErkDog has departed, it was all good until his an Fyren's last post. I'm not so sure about the "responsive enough" part, Fyren doesn't speak for all of us. That said I'm pleased that we're being kept in the loop as progress is being made. --Xasxas256 03:16, 15 November 2006 (CST)

Just trying to do some damage control here. I don't really blame Fyren, I can understand his reaction. It wasn't exactly totally uncalled for. Actually, ErkDog's comments towards GuildWiki on forums over the last few days were more and more hostile. Fyren obviously knows his ins and outs as a server admin, and is not in urgent need for advice. (He's in need for better hardware. ;)) But - like Xasxas said - discussing proplems and possible solutions in public can never be wrong. Many of out users work in IT as server admins and there may be people among them who's advice is definetly worth listening to, and turning down people who try to help gives the wrong message.

I've read various forums a lot over the last two weeks (wasting my time away as the wiki is down ;)), and the amount of negative comments I've read about GuildWiki's responsivenes really worries me. Many of our users do not read the GWiki talk pages (even when the wiki is fast, let along when it's creeping slow or not accessible at all). They only see the sitenotice (which doesn't tell much and hasn't changed in almost two weeks), and the little bits of information on the GWGuru news and forums (which are not very informative and positive either). I trust that behind the scenes Fyren and Gravewit are working hard to solve the problem, but the public doesn't see that. To our average user it looks like we're sitting on our asses, not doing much about the problems, and even have the nerves to turn down offers for help. All in all, our PR is LOUSY at the moment!! That's why I asked for a bit more transparency [1], via the site notice, via our GWGuru forum, and via the gamewikis blog. Maybe Gravewit should ask Gaile Gray to teach him a bit about "community relations". :( /sarcasm -- 04:28, 15 November 2006 (CST)

Yeah Tetris, I agree with you on the PR front. People don't read talk pages, especially not when the server is as slow as it is at present. I think it would make a lot of sense to put up a notice explaining the current situation. <LordBiro>/<Talk> 06:41, 15 November 2006 (CST)

Well squid obviously isn't doing it's goddamn job then. If you claim it has all the pages cached and keeps them until MW tells it to purge them. Otherwise the Wiki would NOT be ridiculously slow, and Squid would be taking the large majority of the page hits, obviating the load from HTTP and the Database. HTTP would not be "overloaded" There are NOT that many updates that should be kicking pages out of Squid. And I stand corrected on the purge. It wouldn't surprise me if Squid is on the same damn server as the HTTP. But I wouldn't know because Fyren refuses to answer any questions about the overall configuration of the damn wiki servers. If the box w/ HTTP and Squid on it is overloaded, and the MySQL server not under load, how much sense would it make to have moved Squid over to the MySQL Box? But I find it difficult to believe that the Squid server was so pounded that it can't serve pages. Especially since Fyren indicated specifically that HTTP was overloaded. But by all means, GameWiki should continue to refuse to share configuration information and let it's Wiki remain slow as balls. If Fyren meant to say that the SERVER with http and squid on it was overloaded, then that's what he should have said. But Squid clearly isn't taking the load off the HTTP it should be. Serving static pages is not resource intensive. Fyren claims that MediaWiki is slow. That become irrelevant when a Squid process is serving a cached page. I also find it difficult to believe that that counter doesn't kick pages out of the cache. That counter is a part of the page, and it being updated should and most likely does tell squid to kick the page. Turn the damn counter off, it's frivolous and even if it DOESNT kick pages out of the cache it's extra database queries for no reason on -every- friggin page. Given my post Fyren's response was not unexpected. I don't really care about that. What pisses me off is that nobody will share any goddamn information about the Wiki. This entire conversation has been nothing but vague information and horse crap. Nobody can have a productive conversation about anything relating the servers or mirrors because nobody will provide any friggin information about anything. Everything is met with vague responses or no response at all. Fyren will argue adamantly that Squid can be told to purge a page. But won't bother to comment on the Mirror system I laid out. Good thing that the GW staff takes the time to talk about the -important- things. Whatever. ErkDog 06:58, 15 November 2006 (CST)

Lol Tetris, as outlined above, most of the things I've mentioned here have gone either Ignored, or been sidestepped with vague answers. The first round of posts I made here ON THE TALK PAGE, went completely unanswered for over a week. Like I said, it's good that Fyren can take the time to wax over the configuration of squid, but not elaborate on useful things that could serve as a catalyst to improving the wiki's performance. One of those pages could have been referenced far earlier into the conversation instead of letting it progress to the point it did. But it's really moot, had the conversation taken a more appropriate path, squid would have probably never even came up. Since you guys seem so reluctant to setup real mirrors, and since you also seem to not discuss it worth a crap, I was merely brainstorming. And Fyren hopped on one obfuscated point rather than hold a productive conversation about mirrors or server configuration. ErkDog 07:09, 15 November 2006 (CST)

I've just been browsing through this and burst out laughing. ErkDog, get a hold of yourself. You aren't the only person in the world that knows a thing or two about server hosting. Yes, a fresh set of eyes may help, but it should have been painfully obvious by your second message that Fyren does not need or want your help. The fact that you keep coming back and then throw a tantrum when you don't get your way is just astounding. 68.209.230.87 03:48, 16 November 2006 (CST)

Lol dood whatever. It has nothing to do w/ getting any body's way. 100% of my annoyance comes from lack of communication on the GWiki staff or their lack of contribution of salient information.

I can't share the current server setup, as it's currently been in flux, and my information is out of date.

I can't tell you how transparent we're going to be, because I don't know. I can tell you that Fyren has significantly helped, in that a server admin is now discussing things with the wiki in general, even in a limited fashion.

However, I can tell you that Squid does not work the way you think it does. For example, Squid is not serving any of the requests that you or I submit, because we're logged in. If Squid served the pages, you wouldn't get that nice link to your userpage at the top, and you wouldn't get notifications that people have edited your talk page. Thus, Squid is not serving the overwhelming majority of pages here, as you think it does.

Squid is not the magic bullet for GuildWiki. While we appreciate your attempts to help us, take solace that we've done quite a bit of research on Squid, memcached, and load balancing solutions, and are evaluating every possible solution for merit and cost. If we come across any specific implementations that we'd like advice on, we'll certainly ask the community, as we know quite a few talented administrators frequent the GuildWiki.

—Tanaric 23:41, 16 November 2006 (CST)

Between the fact there are a lot more anonymous users than logged in users and that most pages have at least a few images, the majority of requests are for "anonymous pages" and images. So by number of requests, squid is doing a lot of the work. Unfortunately, that work is the easy work. We were already using a crappier cache strategy for anonymous pages before squid, but rendering the pages for logged in users is where the the problem was. While everything but the DB was on the same machine, using squid dropped the CPU load a lot, but the difference was like going from "incredible amounts of load" to only "way too much load." --Fyren 00:01, 17 November 2006 (CST)

"Fake" pageviews cause server slow-down?

According to our stats we have more than 200 million pageviews. According to the list of largest wikis that's FAR more than ANY other wiki out there, including the largest wiki of all, English Wikipedia, which has more than 100 times as many articles and 150 times as many users as GuildWiki, but "only" 65 million pageviews.

I simply can't believe that. I take it, either the GuildWiki statistics are incorrect. Or, if they're not, then it would definetly be worth investigating the reason! Has it occured to anybody that this may be one of the reasons behind the mysterious slowness we're currently experiencing? Maybe "something" on the server is generating "fake" excrescent pageviews, eating resources?! Kinda like an internal DOS attack. I'm not an IT techie, and I know very little about MediaWiki, MySQL and Apache, so I've got no idea what exactly may be causing a "pageview multiplyer" effect. It's just a hunch. Maybe somebody with more knowledge than me could look into it? -- 02:35, 14 November 2006 (CST)

The view stats for enWP are just from whichever of their many servers was queried at the time, not a total. You'll note the stats indicate there have been more edits than views. The WMF servers easily get millions of article views a day (this suggests enWP has been getting about 4.6m views a day on average lately). Also, the reference nature of a lot of our content means we have a lot of small articles that often get quick looks and lots of clicking around (comparing skills, looking up item stats, viewing armor images/crafting info, etc.) whereas other wikis probably have longer articles you don't fly through in one sitting. Our numbers are accurate but a straight comparison doesn't take everything into account. --Fyren 03:22, 14 November 2006 (CST)

What you say makes sense, and checking the list it is very obvious that the pageview stats are bugged. But I still find it hard to believe that out of 120 wikis we are the only ones with correct pageview numbers. We beat ALL other wikis by number of views total, views per edit and views per article, and all except two by number of views per user. That smells very fishy. -- 03:50, 14 November 2006 (CST)

A lot of those sites may just have the page view counters off, freezing the reported views at whatever they were at. I'm too lazy to look through the page history to see which have been changing and which haven't. I noticed Wikitravel's hasn't (checked since they have a similar number of good articles and edits to us). --Fyren 19:57, 14 November 2006 (CST)

Reboot

Changing a setting that'll require a server reboot to take effect. Probably doing it around 3 AM EST, shouldn't be any interruptions besides that. Dunno if you want me (or whoever) to put it in the site notice since it'll be minutes at most. --Fyren 23:22, 14 November 2006 (CST)

Don't bother. People have become so used to GWiki being down that they won't even notice. ;) -- 01:55, 15 November 2006 (CST)

I'd like to say that if we're going to improve the GuildWiki, be more accountable and helpful to the community we should let them know. But at this stage I'd just go ahead with it. --Xasxas256 02:21, 15 November 2006 (CST)

Guild Wars Top 200 anyone?

Guild Wars Top 200 has quite a few sites in it, but no GuildWiki? While these kind of websites are 10 a penny we can't let them have a list without GuildWiki can we? Just out of interest, I accessed this link from GuildWarsGuru, I generally don't click these kind of things but when I noticed GuildWiki wasn't in it, I was appalled. --Jamie 05:54, 15 November 2006 (CST)

We don't need a measly site like that to tell us that we're Kind Of A Big Deal, do we? ;) Hell, how do they determine their rating anyway? Most of the sites they list are not listed on the official fansite listing, and vice versa. Their listing means absolutely NOTHING. Simply forget about them. -- 07:22, 15 November 2006 (CST)

When people ask questions in-game, they are directed to the wiki. Nobody directs them to that gonzo listing, so I frankly couldn't care less whether we're on it. The measure of worth we're looking for here is actual use by players, and I think the wiki has succeeded in that. Kessel 22:38, 15 November 2006 (CST)

Stats: Users by number of edits

I'd really like to see stats like this for GuildWiki. Can an admin (Fyren?) install the necessary add-on please?! :)

Disclaimer: I do know that the value of a contributor should not be judged by the quanity of his edits, but rather the quality.

I've seen enough idiot forum spammers bragging with their postcount to know that the sheer number alone means little. But I'd still like to know, out of curiosity, and because I'm losing overview of all the regular contributors. If you want to, you can hide the page somewhere so that the average user doesn't see it. ;) -- 06:17, 17 November 2006 (CST)

Personally I hope this doesn't get implemented. I'm surprised Wikipedia implemented it. <LordBiro>/<Talk> 06:34, 17 November 2006 (CST)

I don't see a big deal about it. No one seemed to get bent out of shape when Special:Mostlinked was discussed about users rank on the list, see Skuld's talk page. No one that I know of uses that page other than to see who adds the most comments on talk pages. There is also the page that lists what number you are when registered. Forgot the page, but says like LordBiro is the 6th person to register on wiki and I'm like the 1633rd person. That doesn't make us any different, except I was late to get involved in the Guild Wars community and I see you have fun with that little statistic as people do with most linked page as well. It would not serve as being a fun little page, but would be a nice quick reference tool to those that wish to use it as such. And in using the quick reference, you can see what type of information, if anything, a user concentrates on. You can tell by my edits for the most part are unique items, bestiary, and categories.

Obviously there are negatives to every action we take, but we always believe the positives will overcome any negatives that come from implementing new ideas. Everything can be viewed as such, policies have their positives, but sometimes people use them for negative purposes to get their way. Yet the policies stay, mostly untouched, because the good outweighs the bad, as in the case of the special pages. — Gares 08:06, 17 November 2006 (CST)

User:Fyren/editstats. --Fyren 08:45, 17 November 2006 (CST)

ZOMG, Ollj has more edits than you, Lord Biro! :) --Karlos 09:10, 17 November 2006 (CST)

So that's why LordBiro didn't want to see a list of number of edits. :P — Gares 09:19, 17 November 2006 (CST)

Lol, my secret is out! :( <LordBiro>/<Talk> 09:30, 17 November 2006 (CST)

Why, of all places, did I have to be 69th? --NieA7 09:45, 17 November 2006 (CST)

What's wrong with being in position 69? :) -- 09:47, 17 November 2006 (CST)

Saved by one edit, good grief. Kessel 10:51, 17 November 2006 (CST)

Fyren: Three questions:

1. Will that page be updated?
2. Any chance to see two stats: 1) All time, and 2) in the last ... lets say ... 4 months?
3. Any chance to separate the stats into talk page edits and editorial content edits?

-- 09:34, 17 November 2006 (CST)

You're never happy, are you Tetris L? :P <LordBiro>/<Talk> 10:00, 17 November 2006 (CST)

In Germany there is a saying for it: "If you give him one finger, he grabs the whole hand." ;) -- 10:29, 17 November 2006 (CST)

It's suprising to see two IP addresses with over 400 edits.

I do agree with Tetris that if the site creates this as a regularly updated list, that it would be more useful to see edits in a rolling three or four month period, and to have talk (and maybe user page) edits omitted from the counts. --- Barek (talk • contribs) - 10:38, 17 November 2006 (CST)

I don't want talk page edits omitted from the stats. Discussing things is an important part of contribution. I'd just like to see them separately, so I can see who the chatty guys are. ;) -- 10:51, 17 November 2006 (CST)

I'd agree with that. It's kinda nice to see my name on there too. Didn't know I've had that many nor that I'd be listed in the top 100 even. I thought there were more contributing and contributing more often than me than what I saw there. Kinda puts thing in perspective a bit. To compare an example, I guess you can say polls aren't ever accurate either but they can still give some useful information for those familiar with the limitaions of one.-- Vallen Frostweaver 10:57, 17 November 2006 (CST)

I was really surprised to see that I'm #11. (and two of those in front of me are bots) I don't think this would be a bad thing as a regular special page, but even a "hidden" regularily updated page with some sort options (as mentioned by Tetris) would be great. Hmm, I think I'll see myself in top ten soonish as Stabber and her bot are not too far. -- (talk) 11:06, 17 November 2006 (CST)

I was this close (holds up two fingers approx. 1cm apart) from a bronze metal. :P --Rainith 12:00, 17 November 2006 (CST)

Tetris wrote, I don't want talk page edits omitted from the stats. Discussing things is an important part of contribution. I'd just like to see them separately, so I can see who the chatty guys are.

See Special:Mostlinked. I doubt you'll be suprised who the chattiest of them all are. ;) — Gares 12:18, 17 November 2006 (CST)

The problem here are sigs like mine which originally linked to my user page, but now to my talk page. Talk page contribs would be much closer to the reality. -- (talk) 12:44, 17 November 2006 (CST)

Nice, I beat Tanaric by two edits. ;) Make that three edits! --Rezyk 15:47, 17 November 2006 (CST)

Huh? Who is "27. MediaWiki default 1902"? Is that scripts from system setup, or a system admin in god-mode? --- Barek (talk • contribs) - 15:51, 17 November 2006 (CST)

This was generated using a dump of the article revision metadata and a four line Perl script. I'm much too lazy to write something to separate things out by what's edited or the edit date. If someone wants to write something "interesting" for me to run, the data looks like this: User:Fyren/revdata. --Fyren 20:51, 17 November 2006 (CST)