I realized today that while I've talked a lot about how I curate content for NodeConf I've never actually written about it. Some of my influences have written what they think and what I'll be covering is an iteration on their thoughts bent toward achieving my own goals. If you have a moment you should read Chris Williams and Malte Ubl.
I have very little aversion to risk. This should be taken in to account because a lot of what I'll say won't be followed by most conference organizers and nobody should think ill of them because of it. Most people have to worry about selling all their tickets and not going broke. I'm lucky, I ran my first NodeConf with Chris Williams helping and it rode on the coat tails of JSConf so I didn't have to worry about making any huge mistakes or not selling all my tickets. By the time I did the second NodeConf I was confident that with node's popularity I'd have no problems selling the tickets and that emboldened to make the it the best conference anyone had ever been to.
In planning the third NodeConf I've had to identify some guiding principals for what NodeConf needs to be.
The first principal is that NodeConf is what I think the community needs, not what the community is asking for. Last year, hardly anyone was asking for talks about hardware but all my closing talks were hardware and they killed. I'm in a unique position for NodeConf because I'm deeply invested in the community and spend a lot of time travelling and talking to people about what they are doing with node. This access allows me to find content I wouldn't be able to find otherwise.
NodeConf is selected. I might do a reverse CFP to get an idea of what people are excited about but it's not my primary guide in developing and selecting content. I settle on the subjects I want to cover (realtime, hardware, debugging) and then I seek out people who can best fill it in.
The second principal is that everything should be new. The format should be new, the talks should be new, and hopefully the food should be new. So far the venue has always been new but I reserve the right to change that. Changing the format means that when I solicit talks from speakers they have to write something new. This trick only works once which means I can't recycle a format year over year. For the second NodeConf I did acts of 4 talks that covered a subject with each talk only lasting 20 minutes. Having such a short amount of time meant that nobody could use a previous talk and nobody could cover foundational information before their subject which forced the speakers in an act to work with each other so that each talk lead in to the next. An important part of this was that I didn't post a schedule publicly, which insured that nearly every attendee was in every talk. If you aren't able to insure that everyone is in all the talks in an act you're limiting how much the talks can lead in to each other and the speakers might get poor feedback about their talk because they didn't cover what was in the talk before them.
As connected as I am to the community I can't know everyone but I can and do know enough people that I can get connected with who I need. I didn't know who was doing the most interesting realtime development so I asked Guillermo Rauch and Daniel Shaw who I should talk to and they referred me to Mikito Takada and after a good conversation he understood what I was looking for and created a great talk. People seem to think that process like CFPs and voting will produce a higher quality but I've found that having real conversations with people is the best way to get new and creative content.
The third principal is that the surface of content should be as interesting as the information. I stole this from high end culinary culture where dishes must look as appetizing as they taste. Hardware talks get this almost by default because they have physical interaction which is interesting even if you don't care about the code or the process. A talk that tells a story in order to convey information will hold attention and interest much better than a talk that does not. The best example is Stuart Memo's "JavaScript is the new Punk Rock" from JSConf.eu 2012 which incorporates physical manipulation and demonstration in to a story and technical explanation of audio APIs available in the browser.
The parties must also follow this principal. JSConf does this wonderfully where all the parties re-enforce the "theme" of the year and are fun. In the second year of NodeConf I had a party at a karaoke bar with an API written in node.js and a party where all the music was created by node developers including the newly formed "Stream or die()". A portion of the attendees are looking for an excuse not to go to the party and having a hook like a theme or a fun activity like karaoke or bull riding will help get them there instead of relaxing in their hotel after a long day of conferencing.
My final principal is that the conference must be a true experience, which I've taken and adapted from Funconf. I care about building community which means that I need to find ways of getting the attendees to connect with each other. Talks don't do this at all, talks convey information one direction and enforce a separation between the speaker and the audience and sometimes between the audience members. If the conference becomes an experience, if it's like a ride that you get on with everyone else, when you're off the ride to eat or relax at one of the parties everyone shares that experience and feels connected.
These are pretty simple principals but they effect every decision. Last year the format I created was adapted and used by several other conferences which was a great compliment and a testament to how effective it must have been but the fact that its become popular means I'll need to create something entirely new this year. Most conferences build and iterate on their format rather than destroy them entirely to start from scratch each year. I do this because I'm more excited about NodeConf being a leader than I am in running a conference just to have it. Running a conference each year can be a burden but forcing myself to be creative lends me the energy I need to keep it happening.