One of the big reasons that I ran ShuffleComp in the first place is that I felt there was a need for moderate-pressure, fun-oriented comps in the IF space. Now that it’s done, I feel that we absolutely ought to have at least one event of that nature a year. I really don’t want to always be the guy running it. So, for the benefit of anyone who wants to run one in future, here are some things learned or confirmed.
Things that went well:
- Do something different. This means knowing the events that already serve the community you’re drawing from, understanding how they work and what needs they serve, and having some ideas about what’s missing.
- As part of this, have a compelling concept. This should be pretty obvious, but it bears repeating. Concepts which give every author their own individual material relieve at least one kind of pressure on authors – you don’t have to worry that someone else is writing a game about the same thing and doing it better. It’s also helpful if authors are offered options: a single writing prompt might not jive with some authors, so offering a range boosts your odds.
- Brainstorm your concept in public fora beforehand. Thinking out loud will clarify your idea. People will ask questions and suggest refinements that might make your idea more compelling – or at least let you identify and address issues that might make potential participants anxious. You’ll be a lot happier about making rules clarifications and changes before everything’s up and running. As a bonus, this gives you some idea of whether the event will attract interest; and if so, then the process builds on that interest and gives people some more time to pencil you into their schedule.
- Be flexible. Your original vision isn’t what matters. (That said, if you’re running anything, you really need to be prepared to make the final call on things. Crowdsourcing will not always offer you consensus, and the customer is not always right.)
- Self-promote with social media. Yeah, I know, I know. But you can’t assume that everyone you want to reach can be reached in one place. (In the IF world, circa 1997, that was a safe call. No longer.) If nothing else, get into the habit of using Twitter, which a lot of authors frequent more than they do intfiction.org. (This assumes you’re aiming for maximum participation, of course; you might want to keep numbers more manageable.)
- Expect some participants to drop out. Don’t design an event that structurally relies on everybody staying in. Some mild pressure to stay in helps, but you want everyone to have a good experience, including the people who drop out: work to avoid making anyone feel guilty.
- Seek and accept help. Shufflecomp got volunteers for file hosting, vote counting, and betatester-exchange organisation, without really having to push very hard.
- You will forget something important or fuck up at some point. Probably at several points. When you do, be transparent and honest about it, apologise, and go for the solution that best serves your users, even if it’s an inelegant bodge-job.
Things that could perhaps have been done better:
- Make sure that your methods scale if you’re more popular than expected. I expected to have about 12-15 participants, leading to maybe 10 games; the methods of organisation became a lot harder and more error-prone when I was got 51. With the numbers I expected, personally trigger-checking every song would have been a light task; with 400+ songs, it got a bit silly. Similarly, I ignored suggestions that I should use form submissions and shuffle songs using a spreadsheet – the make-your-own-form sites were a bit uglier for all-text entry than I’d have liked, and the random-sort method was a little more fiddly than I felt comfortable implementing in spreadsheetese. This ended up creating a lot of scut-work.
- Be really methodical about communication and resolving issues. I relied way too much on keeping to-do lists in my head. This, again, is a scaling problem; when there are fifty people you have a lot more special requests to keep track of. Keep a to-do list and keep it updated. Religiously.
- In retrospect, it’d have been much less work to host files somewhere I had direct access to, because one error and another meant quite a few updates; the result was kind of a game of email-tag, bothering two people where only one should have been necessary. (Here the pseudonyms actually worked against me; authors couldn’t contact Matt directly, or host their own games, or whatever.)
- Don’t rush updates or announcements, even when – especially when – your participants are champing at the bit. You will never be fast enough to satisfy the Internet, and you’ll only make errors if you try.
- Don’t start a comp when you’re still organising another IF event, enter your own event, and aim to make a relatively ambitious game. Or otherwise arrange matters so as to overstretch yourself. Worn-out, unfocused organisers are inefficient organisers.
If you’ve never organised an event like this, it doesn’t hurt to start small. A Speed-IF type event, announced a week or so in advance and run over a weekend, is pretty much as easy as you care to make it: you don’t need to worry about voting or hosting or promotion, just pitching the idea and setting a schedule.