Turning Over the Reins, Pt 3
Ok, so now we have some idea of how to transfer leadership and have gone into depth on the things that guild leaders do. Now let's talk about ways to make leadership transitions easier.
Even if you're not going through a leadership move right now, adopting some of these ideas will make it much easier when and if that day comes. And if it never does, you still end up with some neat benefits.
In the course of this article, I'm going to make reference to a few specific companies and/or products. These are simply ones that I use or are familiar with. If there's a link to them, it's not an affiliate or referer link. If you know of alternative providers or products, feel free to mention them in a comment, but keep the links generic. Thanks.
Making Contacts Generic
Much of the things that you need to transfer can be made easier by using generic contacts rather than specific people. Create an email account for the guildmaster, one for the webmaster, one for recruiting, and so on. Even if one person does all of these jobs, create separate email addresses so that you can split responsibilities up. Then forward the mail from those accounts to the actual person doing the job right now.
In all of your web apps and online contacts, use the pseudo-aliases rather than personal email addresses. This way, when the person doing the job changes (even just temporarily) you can just go and change where the forwarding points to rather than re-configuring the thing that sends the mail.
If you intend for people to be able to reply from the pseudo-address, you may need to be more selective in the manner you get your email. Most desktop email clients let you change the "From" address in your emails. Some let you swap between several on the fly. Not as many web email systems support sending with alternate From addresses, but Google mail does. If you've never set it up, it's easy. Go into your gmail settings and select the Accounts tab. Then click on "add a mail account you own". This will send an email with a link to that address. Log into the other account, click on the link, and you'll be able to use that as your From address when replying to emails.
You can also set gmail to make the From address sticky: if someone sends mail to firstname.lastname@example.org which forwards to your personal account, you will by default reply as that account. This will save you from accidentally exposing your personal email address.
There is one caveat: once this "send as" functionality is configured, you can't revoke it. If someone leaves the guild, they can continue to send as email@example.com. But if they were using a desktop mail client like Thunderbird, they could do the same thing. Remember, you can never trust the "From" address on email. You can't really trust any part of email, to be honest. The underlying tech was developed in a simpler time before spam and malware. Backwards compatibility preclues massive changes to email to make it more secure, so you just have to live with the way it is.
When it comes to services that require exchange of real money, you can probably get away with using a generic email address, but you can't make up a generic name for payment details (nor would you want to). You will have to go in and change these details, and ideally the person leaving the role will remove their billing details from the account before the next person takes on the position. At least by using a generic email notices about the account (like "your Ventrilo service is due to expire in two weeks") won't be sent to someone who is no longer associated with the guild.
Your Own Domain
The cost of setting up a domain for the guild (as opposed to using a subdomain of a hosting service) is pretty small - on the order of $10 a year. The problem is that you do need someone who has some background with web sites and the underlying tech to make it all happen. Some web providers will let you register and host the DNS (domain name service - the thing that turns www.yourguild.com into the address of a computer on the internet) all from one place. Others will require you to set up each component (domain registration, DNS and web hosting) separately.
Even for providers who will do everything from one place, the cost may be cheaper if you do it yourself. For example, GoDaddy lets me register my .com cheaper than my web hosting provider did, but not my .co.uk address. There are of course advantages to having all your domains hosted at the same place, but if you're looking to minimize costs, consider using the cheaper option based on what type of address you're registering.
There are a few things to bear in mind when choosing and setting up your domain. If you plan on using something like Google Apps (more on that below), then you will need to be able to edit your DNS records directly. Some providers don't give you this level of control. Also take care when choosing the admin, technical and billing contacts for your domain. It's quite common to set these to the same person and for that email address to be in the domain itself.
The problem is that if anything goes wrong with your DNS, you may not be able to get the domain back because the provider can't send you email. It is safer to go set up a separate Yahoo/Google/Hotmail account called firstname.lastname@example.org and use that for your domain contacts so that you can still converse even if the domain records break.
Speaking of registration deadlines, don't miss those. Your guild domain name may seem to only be of value to you, but domain harvesters look for expiring domains, snatching them up if the legitimate owner misses a deadline and then trying to sell the domain for much more than the registration fee. You don't want to be in the position of buying back your own domain.
Hosting Everything Yourself
If you have the technical skill, you can host everything yourself. Providers sell virtual servers, which are full Linux or Windows machines onto which you can load anything. You set up your own web server, FTP site, third-party packages, whatever you like. I use a service called Slicehost to do this - this blog runs on a 256mB slice that I pay $20 USD a month for. In addition to wordpress, I have Gallery, a Wiki, MySQL and a few other little packages. If I was really adventurous, I might even try this newly discovered open-source voice service called Mumble, which would eliminate the cost normally associated with a Ventrilo service.
The advantage to this service is that there is nothing I can't set up quickly and play with. I don't have to wait for my hosting provider to approve a piece of software, then live with whatever upgrade cycle they choose.
The downside is that this requires a very skilled technical person, and it will be hard to transfer the knowledge required to set up the server to someone less technically knowledgeable. Don't use a system like this as an opportunity to learn how to build your own server - at least not for the guild. You are responsible for everything - the web server, the firewall, the database, and security. Simple mistakes that you make when learning can leave your guild site open to abuse or hacks.
If you want more control than a guild hosting site provides but you aren't ready to jump into a virtual server, try to find a shared hosting provider that allows shell access. Before I was on a virtual server, I used a company called Dreamhost for this. While the web site rendering was quite a bit slower, I did have the flexibility to install whatever web packages I wanted.
Sharing the Cost
As I mentioned in Part 2, some providers offer easy ways for your members to chip in towards the cost of hosting services. You tend to find this on things like Ventrilo (which is more gamer and thus more guild oriented) than on web hosting plans.
If your provider doesn't offer such a plan, try to find one that accepts Paypal. Then your members can send you money via Paypal and you can use that balance to pay the hosting charges directly without having to futz about getting the donations into whatever account you pay your credit card from.
The downside here is that Paypal does not allow you to open multiple accounts for the same person, and the accounts need to be verified, so you can't help but expose personal email addresses that way. You can use whatever email address you want though, so you could set up a paypal-specific email account. Just remember to check it regularly or forward it to your primary email account.
Do take care to read the specifics of the Paypal payment options though. They differ by country, and in some countries payments made by credit card can't be accepted by a personal account, or they have a fee attached to them. If your members haven't linked their own bank accounts to Paypal, you may end up with pending payments that you can't accept.
No matter how you set up your guild website and voice communications, you're going to end up with a few systems that have various permission sets. Your forum, your FTP site, your screenshot gallery, your DKP system - all of these may have accounts that allow officers to do some of the work. Make sure you set up this level of access. There's no point in the officers being able to act in your stead in-game only to be unable to add new members to the web-based loot standings or approve new forum members.
When setting up these permissions, it's tempting to be more restrictive than is really required. Remember that you want to set up permissions that let the officers act in your stead. Either you make the officer permissions open enough that they can just do your job when you're not around, or you bump an officer's access up to your level any time you're going to be away for a while. The former will cover unexpected absences while the latter will not.
A Wiki is a shared webpage that multiple people can edit. It supports simple markup to create lists, tables and links. Most people are probably familiar with Wikipedia. Imagine a Guildopedia just for your guild.
Keeping track of all the information about your guild in forum threads can become confusing. Changes aren't tracked, and sometimes people can't tell when things have changed. A wiki is a good alternative for this for things like policy and tutorials.
In one guild, I used a Wiki for two things: to document policy for users and to provide "here's how to run the guild" pages for my officers.
There are many wiki packages out there: some you run on your own server (which require shared hosting or a private machine) and some are hosted. Among the hosted options, you usually have to pay to be able to restrict reads to certain groups. If you're going to put information that only officers should read, you need tobe confident that your wiki is going to prevent other people from finding those pages. Mediawiki, the software that runs Wikipedia is very nice, but has some issues with this: pages that are supposed to be protected can be found via searches, and the search result excerpt may expose information even to those who aren't allowed to read the whole page.
I've had a lot of success with a wiki package called WikkaWiki. It offers nice clean access control including groups, and search results are properly hidden if you can't read the page.
Twitter is a great way to send quick updates to the guild out-of-game. Set up an account in the guild's name, sharing the password among the officers. Ask your members to follow the account, then use it to post about raid schedule changes, important forum posts to read, first kills and the like. Be careful that it doesn't become a "stream of consciousness of the guild leader" though. Take care as to whether you protect your tweets or not. If you do, you have more work to do to approve followers. If you don't, you will get spam-bots following you and you won't be able to post anything that is considered private to the guild.
I'd like to take moment to discuss Google Apps, which is a free service offered by google to host your domain. It can provide a start page, webmail, documents, and calendar sites, all using your domain name. I have this set up for cold-comfort.org, and I use it to store things like spreadsheets for blog posts. I can offer my guild members email addresses @cold-comfort.org, and create any number of pseudo-accounts for billing contacts or test users for my forum.
I then forward these accounts to the proper personal email address (which is my personal domain, also using google for mail) and use the aforementioned "send as" feature so that both my personal and guild mail end up in the same inbox.
You can use Google Calendar for raid signups, though it's obviously not optimized for things like limiting signups by raid roles. You can organize people into groups (so members / raiders / officers /etc.) and then use those groups to protect documents. Rather than setting up a Wiki, you could put all the passwords and tutorials in Google docs documents, then restrict them to only be readable by the proper groups.
Depending on the complexity of the spreadsheet, it might even be possible to take some of the theorycrafting sheets and upload them. Google docs can't do everything Excel can do, but the functionality is surprisingly good for a web app.
It's even possible now to upload any file to Google docs (with a 1gB limit, but you can pay to increase that), so you can use it like an FTP site to store addon packages or short guild movies.
Setting up Google apps for your domain isn't terribly difficult, but does require a bit of knowledge of DNS. For the technically minded, you create a CNAME record with a special key, which Google then looks for as proof that you are the domain administrator. This is why I mentioned earlier about choosing a DNS provider that gives you full control of your domain - if you can't create CNAME records, you may have trouble bringing your domain over.
Regardless of how you host your site and voice communications, make sure that somewhere there is a list of everything the guild uses to provide service to the members. Any third party package, any hosted site. This can be in a forum thread that only officers can read, a wiki page restricted to officers, or a Google docs file that is shared to the appropriate group.
Make sure that this is kept up to date with information like who is paying for the service (if applicable), the date that the service runs out, the email address that members can send donations to for each service, etc.
If you choose to use a single account for officers to access various parts of the guild website rather than accounts for each person, those details should also be stored here.
You should also consider writing quick little guides to help your officers learn how various guild functions are performed. How do they collect loot details for upload into WebDKP? How do they do decay in EP/GP? How do they give a new member the proper access on the forums, or in the scheduling system? How do you add a new room to the Ventrilo server? Having these tasks documented before a leadership break or transfer happens will do wonders to ease the job.
Changing Passwords When Leadership Changes
If you do use shared passwords, make sure you change them when someone who knows those passwords leaves the guild. Don't only do it if you think that person might misuse the passwords. Security is best applied consistently - don't try to make a judgement call on someone only to learn to your regret that you guessed wrong. If you change them every time then it's about the practice, not the people.
Yes, this is more work, and a bit of pain for the people who use the passwords. But it's the safe way to do things. At least if you've documented all the places the passwords are used you can build a checklist.
Testing as a Regular user
Most of your guild websites will have several grades of users: unregistered guests, registered guests, guild members, guild officers and the site administrator or guild leader. If you're always logging in as a privileged user, you'll never be aware of problems with your permission system. You don't want to make a post that is intended for officers only to find out that the forum you posted in is readable by all and only writeable by officers.
To address this, I create a dummy account for each grade of user (except unregistered guest, which is defined as anyone who visits the page without logging in). Any time I add a forum or change permissions, I log into each of these accounts in turn and make sure that the changes look correct for each class of user.
Hopefully this last installment has given you some ideas that are useful whether you expect to be changing leadership in the future or not. Or perhaps you're starting a guild, and these tools will help you make things better from the start.
I'd like to thank Veliaf for the question that led to this series. If you have any questions or ideas for articles that I haven't covered in the past, please feel free to get in touch: email@example.com.
Until Next Time