QuakeNet has problems. It's a know fact, and quite easily seen when using the network. A lot of our problems originate with you guys: the users. There are quite simply too many. QuakeNet has in the last couple of years had approximately a quadrupling of users every year (see netsplit.de for statistics of pretty much all irc-networks in the world). This has given us problems in various areas, most significantly in the support area. Originally all support was given in the channel #feds. When the user count reached a certain level it became impossible to handle all support from #feds and more and more things were automated. This has led to the current level of automation which also has some quirks. The op request system is sub optimal, as strangers can request ops in channels where they have never been before. Our information system sucks; you guys haven't gotten a chance to figure out what the hell we're doing and although we have written quite a lot of documentation about how to do different stuff on the network, the docs aren't really ordered and finding stuff can be very difficult. The biggest problem that you guys have though, seems to be that getting Q to a channel has become extremely difficult. When it became impossible to keep track of the 'oral' requests being done in #feds Yarn made the excellent web page based queue system.

True, the system has now reached its limits and can't be used without modifications anymore, but it served its purpose very well during the last year or two, and was very good for ordering the at that time chaotic information stream in #feds of Q requests.

QuakeNet also has some problems not immediately visible to the users. The internal structure in the oper organisation has been flat up until now. This structure has been good as long as the individual opers each has been able to keep themselves up-to-date with the state of the network, but now, with more than 80,000 users online every evening, approximately 10 different services to keep track of and about 300 mails a day, the volume of information has simply gotten too big for each oper to be fully updated with at all times. This means that not all opers have the basis for deciding on all things all the time, so some opers specialize in certain areas, and due to the higher knowledge on these areas they will have better grounds for deciding things involving those topics.

_Recent and upcoming changes. 
The general operstaff isn't ignorant of the above problems, even though it might seem so to the general user (this grounds in another problem, more on that later). Several things are being done at the moment to solve these:

My baby is called L. It is a free channel service meant to take the load off of Q. L is just about ready to go in beta testing (no, don't ask to be a beta tester) and should be ready for you guys as a stable service within a month. I wrote a small FAQ for L too, go read. 

Q has been adapted to work properly with L. Apart from that, many small improvements happen to Q all the time, fixing bugs and improving its performance. L was made because Q is very heavy on resources. There isn't really much that can be done to help this, as this is caused by the feature set that Q has. So L has on purpose been designed with very few features. 

O has had a new improved op service implemented, building on an idea we received from EFNet. Its called Chanfix and described briefly works by looking at all QuakeNet's channels every few minutes and checks who has ops. When a channel becomes opless it can then check the statistics for that channel and use the information to help in solving the problem of who should receive ops. This functionality has another function too - it'll be used to determine who should be able to request L to a channel. The idea is that if a person does a takeover on a channel, he/she wont be able to just request L and that way legitimize his holding of the channel. 

*Ircd (the ircserver software) 
The ircd has been improved to let Q and L communicate with each other. A new user mode has been implemented, +r, which allows authentication of an account to survive a service restart or a netsplit. This means that a user can only authenticate once though. Another modification done to the ircd is the implementation of the channel modes +c and +C. +C denies channel CTCP's (pinging a channel for example) and +c denies the usage of colours in a channel (the mIRC extensions only, e.g.. bold and reverse video is still allowed, mainly due to programmatic reasons. It would have been nice to terminate those annoyances too). These have been implemented due to another problem on the network - spam and advertisements. These changes are accompanied by another tool for spam fighting: 

S is the spamscan service. It is available for channels larger than approximately 100 regular users , and basically kills users spamming and/or advertising on the channels that S sits in. It has recently been extended to be able to set glines too in bad cases. 

_Revealing information about the network - a dilemma. 
There is, and has been for a long time, a discussion internally in the oper group about how much information should be revealed about the network. The pros and cons are the usual: revealing more information would keep you guys better informed and perhaps make you more understanding about the problems, but the same information could be used to attack the network. This discussion is ongoing and probably never-ending. It does seem however that the development part of QuakeNet is softening a bit. A development page is in the works and will provide sources for all material related to running the QuakeNet network - hopefully at least. Another attempt at informing you guys better on the general level is also being made. A new homepage is being designed, and will hopefully open up for more information sharing like this document.

Rasmus aka. MnO-Bigfoot 

Ps. I would really like some response on whether you, the users, find information like this useful, interesting, or just dull. Please throw me a line on irc (nick MnO-Bigfoot) or mail me (my nick without the clantag @quakenet.org). Did I forget anything? Well, perhaps I should have said something about the helpers too, but that'll have to wait until the next time write something up.