Noel Rappin Writes Here

I need to say this off the bat: this is my own experience, and does not necessarily speak for or reflect the opinions of Ruby Central, or any of the other conductors who chose individual tracks.

Also, I’m sure I’m leaving interesting things out, ask questions in the comments and I’ll answer.

Are we good with that? Great.

Here are some things I learned from scoring and choosing my little corner of the RailsConf program. Which actually turned out to be a lot of fun.

The thing is: there is an essential arbitrariness to this process. I hope this isn’t a surprise. But we’ve got fallible humans trying to guess how good a 40-minute talk will be from a 500 character abstract plus supporting material. Yeah, there were great abstracts. And there were awful ones. But there were an awful lot that were just really solid. Too many to fit the conference. So you have to pick. And inevitably that comes down to issues such as:

• talks that might duplicate content
• talks that don’t seem to fit the conference or track
• attempts to glean meaning from word chosen and words not chosen
• an attempt to have a range of viewpoints, experience levels, and new and old speakers.

Ultimately, you have to pick what you think is best and hope you won’t get too many people angry at you. I should mention here that I actually enjoyed the reading and rating all the proposals part, not so much the rejecting part.

Making the process blind does’t keep it from being arbitrary, but it does change the flavor of arbitrary a bit.

What can I tell you that might help you in the future? A few things:

Things that get you in trouble

In no particular order, here are four things that got proposals in trouble:

Lack of detail or vague audience

The abstract basically boiled down to “I’m going to talk about X for a while”, leaving out trivial details such as: “What is X?", “Why is it important?", “What will I learn about X?”

The slightly more advanced version of this is a talk that ends with something like “you will learn five techniques for solving your problem with X”. That’s better – and if the proposer put some details in the extended field it worked out sometimes. (Disclosure – I still end abstracts like this all the time. Which does not make it a good idea).

Better is “we’ll learn to do Z, and other techniques that will allow you to do X”. But granted there wasn’t a lot of space in the abstract.

Pitchy

I was surprised at how many abstracts basically boiled down to “my company’s product is awesome” or “my company’s process is awesome”.

Anything that felt like it was going to be a 45 minute commercial had an uphill battle from the reviewers.

If you are submitting a talk about something awesome your company does – product or process – try to make the proposal more generally about the problem. We want to hear about awesome things.

Aggressive

There weren’t very many of these but they were maybe more memorable. Including language or terms in your abstract that seem unprofessional or aggressive was not looked on favorably by the reviewers. Often this was language, some times it was an aggressive or condescending tone towards other developers.

I solved the world

The last category is a little harder to describe… an abstract that basically went like this:

• X is a hard problem
• I solved a particular case of X
• I will generalize my one solution to the entire universe of X

What’s tricky about this kind of proposal is that it’s only subtly different from a really good talk:

• X is a hard problem
• I have an approach that worked once
• Let’s talk about when that solution is appropriate and when it is not

The difference is one of self-awareness and a little bit of humility. The first style sounds arrogant, and not in a good “I’m gonna give a great talk” kind of way, but more in a “I have no idea how complicated this problem really is” kind of way.

Ways to help yourself

The advice from my last post holds, especially Rule One: “Don’t give them a reason to reject you out of hand”. That’s basics of grammar, and the structure of the abstract. Beyond that:

Make Your Argument

RailsConf, like many conferences, allows submitters to submit an abstract, which is public, and a private pitch that only the organizers see.

It was not unusual for the pitch to be stronger than the abstract, I think because people internalize “abstract” to mean “list what my talk is about” and “pitch” to mean “convince people to pick my talk”.

This isn’t academic writing, though, and you want your abstract to convince people to come to the talk. Think about what you would tell somebody to convince them that they needed to see your talk. Include that.

Vote Early and Often

I think there’s a slight benefit in submitting early. About 40% of RailsConf proposals came in the last 24 hours.

In the specific case of RailsConf, if you submitted early you had more of a chance to get feedback from the organizers, which helped a non-zero number of people get selected. The crunch at the end of the time period prevented that level of feedback on the final batch.

Also, a lot of the last-gasp proposals were a little slapdash, almost as if they had been put together at the last moment.

Blind Proposals

RailsConf had an initial round where the bio and name were not connected to the talk, and it was rated by multiple reviewers (at least 3), followed by a final creation of the list, at which time names were attached to proposals.

I’m was reasonably OK with this as a process. I think that the blind review does fulfill the function of forcing the review to focus on what’s actually on the page, and not any knowledge of what the speaker brings to the table. I was unaware of the speaker for most of the talks I rated (in some cases the speaker inadvertently left in identifying information in the talk, which is a solvable problem, and in other cases, there is only one person who’s talking about a given topic – less solvable, but we do the best we can).

In general, the blind ratings were the basis of the final program, while granting that the difference between a talk rated 4, 4, 4, 3 and one rated 4, 4, 3, 3 is pretty minimal, and the conductors did do some curating where there were multiple closely rated talks. (Also there were a couple cases where one speaker had two highly rated talks, and so only one was considered… that kind of thing).

In conclusion

• You absolutely can submit and be accepted to RailsConf even if you’ve never been a conference speaker before. We picked several first-timers.
• The app that RailsConf used is going to be open sourced, so hopefully other conferences will pick up on the feedback structure that we used.
• Sarah Mei is awesome. She rated all 429 proposals.
• Your abstract and details are important. Make sure you are clear on who will get something from the talk, what they will get out of it, and why.
• I’m reasonably happy about the “rate blind, then curate” process. It’s not perfect, but I think it worked out okay.
• I’m excited about the program we picked, and I’m really looking forward to seeing the talks. And hopefully seeing you there.