SwiftBlog

Archive for the ‘Development & Policy’ Category

Before I start I should mention that although I’m making a blog entry, there is still a chance that this software will not be used on SwiftIRC – it depends on if I can get it to work perfectly and if the rest of the staff agree to have it introduced in #support.

I originally intended to write a plan in notepad for myself, but I figured there was no reason why I couldn’t share it with anyone that was interested. This is very much me organising my thoughts and hopefully making the rest of the project more logistically manageable.

If any of you have ever been on GameSurge (another, inferior (;D), IRC network), or used the services package ‘srvx‘ then you may have come across their HelpServ, which is essentially a support queue manager. At the moment in #support we have an eggdrop/TCL bot which helpers use to voice and devoice users in the channel with – it comes with some automated messages when it voices/devoices but that’s about it. In reality the bot needn’t exist – the helpers could do all of this themselves without much trouble. In order to make #support more efficient, and hopefully to reduce several problems that are present at the moment, I’m in the process of copying the srvx HelpServ in order to integrate it with our services. If you’ve used the srvx software before then you may as well stop reading from now.

The majority of the changes won’t be visible to the users – the process of joining and receiving help will be almost identical to how it currently is. The big change will be for the staff members who will have less of an excuse to not help out in the channel.

Before continuing I’ll highlight the current problems with #support.

• Length of time between joining the channel and receiving help – either because nobody notices the join, or people choose to ignore it.

• Certain helpers doing the majority of the work in the channel, letting others to get off lightly without doing much at all.

• Users with questions that could have been answered by the general IRC help channel or the SwiftIRC wiki.

The first two problems are easy enough to fix with the new software, but some more thought needs to go into the last one.

The original intention was to prevent a user being able to receive help from a helper until they confirm with the bot that they have checked the wiki and #IRC help for their answer before asking for further support. Once they’d sent a confirm command or something then they’d be added to the support queue and helpers could ‘pickup’ the users up to help them. Unfortunately this wouldn’t stop users using the command without actually checking the other sources – a time delay could be added to prevent them from confirming within a certain period of time, but that would cause unnecessary bother for those who know that they require legitimate help in the channel. This is something I’m still trying to figure out – I might just end up ignoring this problem altogether.

The first problem will be fixed with the introduction of a staff ‘alert’ system built into HelpServ, which will flood the staff channel until someone responds to whatever set the alert off. Before I get into these alerts I’ll start off by giving a brief overview of the concept behind HelpServ…

When a user enters the support channel they will be placed in the support queue which keeps track of all assigned and unassigned requests. Until a staff member ‘picks’ a user up (which gives them voice in the channel) their request will be considered unassigned and they won’t be able to speak in the channel. Once a staff member is finished helping the user and decides to close their request, or when the user leaves the channel (either by parting, quitting, or being kicked), they’ll be removed from the support queue and will have to rejoin to be placed back in the queue. This process is to keep the support channel organised and to enable us to give better structured, administrative support to the users…

Anyway, back to the alerts. When a user joins the channel they’re assigned an unassigned ticket (if that makes sense), which also holds information about when they joined the support channel. If the difference between this join time and the current time becomes too great (such as 5 minutes) then it will trigger HelpServ to begin whining to the staff channel. The alert will look something along the lines of:

Until those unhandled requests which have been there for more than 5 minutes have been dealt with, HelpServ will whine to the staff channel every minute thereafter..

This essentially gives staff members no excuse to be active in the staff channel and not helping in #support at the same time.

The next alert is when a staff member leaves the support channel, leaving it unmanned. This is a one-time alert, but activates another alert at the same time which messages the staff channel when there’s no helper in the channel but there are unhandled requests. These alerts will look as follows:

There’s also a page command that helpers can use if they’re in #support and need extra help from other staff members (for example if there are lots of users waiting and they can’t handle them all):

Staff will have scripts in their clients which will alert them to when someone uses the HelpServ page option.

Before I move onto stats here are some more random pictures since I’m bored and don’t know what to write.

Result of picking up a user, and then using LIST to view the current support queue:

HelpServ HELP output (excluding a few commands like IGNORE):

When a user joins the channel:

The second problem is hopefully going to be fixed by actively monitoring all staff participation in the support channel. At the moment helpers are allowed to idle in the channel while they’re not helping or even at their computer. This will be changed so that staff members will not be able to be in #support unless they intend to help users. They don’t have to part the channel when there aren’t any requests, but they do have to be actively watching the channel and waiting for new requests to join. By placing this restriction on the channel we will be able to log the amount of time each staff member spends helping in the channel. We will also log how many requests each staff member picks up (so they can’t just idle and do nothing). These stats will be organised into weeks, with time/requests being viewable for the current week, last week, three weeks ago, four weeks ago and the totals. We don’t want to have to place targets that our staff must reach each week, but if people are being left in #support without a helper then we may have to introduce this in the future. These stats will not just be limited to the helpopers – depending on the structure of the support system when this is introduced (if it is), everyone will be expected to do their fair share.

It’s almost 1am and I’m bored & tired so I’m going to stop – I might add more at some other time or I might not.

- Katlyn

Hey,

I realised that it was perhaps time to sit down and write again, in view of the fact that three weeks have now passed since my (fabulous, if I can say so myself) introduction to the SwiftBlog.

Now, I put out a request for topics that users would appreciate some enlightenment towards, and ‘Zanith’ put through a very valid question as to how SwiftIRC’s policies come to be, and how we operate ‘behind the scenes’.

Now, first of all, let me apologise for the fact that the phrase ‘behind the scenes’ was (quite aptly) used. For me, network policies are really things that should be proclaimed for all to hear and see rather than be hidden away behind a ‘Staff Only’ curtain. Unfortunately, I realise this isn’t always possible, and in many circumstances perhaps isn’t desirable for various policy reasons, but I do see a need to correct this somewhat – which is really what I intend SwiftBlog to achieve.

Now, on to the issue at hand: SwiftIRC policies. First of all, I guess it really depends what issue is first being decided, as this will change the scope of consideration. If the issue being decided is whether or not a server should be test-linked, then this is put to a vote before all Network Administrators and Server Administrators. I’m not going to go into the exact guidelines we abide by in this process, but sufficient discussion between this administrative tier goes on such that all of us can make an informed decision. As to the question of why Server Administrators are deemed capable of voting, it comes down to the fact that they are heavily involved at a server-level, and all of them are quite capable of assessing both the technical aspects of the potential server, as well as the more subtle nuances involved in the potential for contribution by the potential administrator.

If the issue is something else, then generally it depends upon the scope and impact of the policy. If the scope is fairly narrow, then usually a single Network Administrator will have, as his or her prerogative, the right to make a decision then and there. If this becomes and issue, then this will be met by a majority vote of the Network Administrators, but for the purpose of practical considerations this is preferable to no decision being made due to the presence of a bottleneck is bureaucratic processes.

If any issue is deemed a bit bigger, such as the appointment of a new global operator, then this will call upon a majority vote by the Network Administrators as this is not something to be solely decided.  In the past, a draft might be presented, which is subsequently redrafted through compromises in successive rounds before being put to a final vote. Regardless of what path is taken, heavy discussion will usually take place in #opers, to various degrees of gravity depending on the actual decision.

Now, if a decision is even larger, such as current plans to revamp the structure of support provided to users on the network, this involves a far more in-depth level of discussion (We even have our own forum to discuss this!), with all staff from the global operators upwards working out what would be best. This is a fairly slow process, but at the same time a wide variety of opinions is infinitely more preferable than a single person make the decisions.

By way of discussion, this takes place in various areas. Firstly, all global operators have access to #opers, where a great deal of real-time discussion is pretty much constantly taking place. To make sure we don’t forget what goes on, we also make use of the forums, for which we have a separate subforum for each tier of staff, including the support operators.

So that’s pretty much how the policies and objectives of SwiftIRC are shaped. Although the hierarchical structure of SwiftIRC isn’t overly conducive to large changes, we feel that they are usually in the best interests of the users as the discussions are infinitely more thorough than any discussion that could be achieved by a single, or even handful of individuals.

Awong

Cower, mortals! Welcome to SwiftBlog!

Long has it been felt that the users of SwiftIRC have deserved far more information about the going-ons of SwiftIRC than has been otherwise available. This is beneficial to both the users and the administration as for the users, decisions that concern their network concern them. For the administration, the aim has never been to sit upon a pedestal, but rather to openly interact with the users of SwiftIRC so that their decisions reflect the best interests of as many users as possible. At the same time, change is being openly embraced as we seek to refine the services and support offered to our users to cater for as many users as possible in as fair and transparent a means as possible.

To serve these dual aims, the SwiftBlog has been set up with the hopes that users will be able to voice their opinions constructively at best, or at the very least have access to an update of the latest dastardly plans going on behind the veiled curtains of the administration. With any luck, these posts will hopefully reveal the rationale behind our decisions as well as our hopes for the various plans we have. As such, I openly encourage all users to take part in this project and share their thoughts as each post is brought out, offering their constructive feedback where possible.

Watch this space, and I hope to see you all around the network, so give me a buzz if I’m about!

Awong