SwiftBlog

Archive for June, 2009

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