RubyConf 2016 CFP

Thank you for your interest in speaking at RubyConf 2016! The conference is November 10-12 in Cincinnati, OH, USA. Please read through and follow all the guidelines below to boost your proposal’s chances of being accepted! If you have questions about the guidelines, you can email us at rubyconf@rubycentral.org.

Topics

We'd love for you to come share your knowledge with ~800 of your closest colleagues & friends. We welcome all talks related to the Ruby programming language, from the mainstream and basic to the niche and obscure.

The only exception: if your talk is primarily about Ruby on Rails, then please don't submit it to RubyConf. Hold off and submit it to RailsConf in Spring 2017 instead. Thanks!

We require all selected talks to comply wholly with our Anti-Harassment Policy. If you have any questions about the suitability of your talk, or anything else in this CFP, you can email us at rubyconf@rubycentral.org.

Proposing a Talk

Talks should be 40 minutes long, which includes time for questions. We encourage you to plan for 30-35 minutes of presentation and to leave the rest of the time for questions. Most talks should be lecture-style presentations, though we will also accept some panel-based sessions.

Proposals can be submitted through September 7. We will be accepting talks on a rolling basis: the earlier you submit, the more likely you are to receive feedback on how to amend your proposal, which betters your ultimate odds of acceptance. Ultimately, our aim is to have every proposal responded to with an acceptance, waitlist, or decline by September 21.

For those of you new to speaking (but passionate and knowledgeable!), worry not: we love first-time speakers and are happy to help you out! If you want to learn more about how to improve your talk submission, read this post. For more information on how RubyConf 2016 proposals are selected, read the "About the Review Process" below. If you have questions after that, we're happy to answer them or aid in other ways -- just let us know!

Tracks

In addition to the general program, we also have a few themed tracks at RubyConf. These tracks have specific guidelines to describe the talks within them. Not every talk belongs in a track. If your proposal doesn't fit neatly in one of the below tracks, either tag it as General or don't tag it at all. However, if you do feel that your proposal might fit nicely within one of the below tracks, tag it with that track name.

Track Guidelines

Tools and Toys

Sublime versus Vim. AWS versus Heroku. Rspec versus Minitest. Rubyists are passionate about their tools, whether they be text editors, test frameworks, or production environments. While it can be fun to bikeshed over a particular tool or technique, we often miss the many ways in which other varieties of our tools can improve our productivity or be beneficial in different situations. Whether it's your favorite gem, editor feature, plugin, or software service, this track is for talks celebrating tools and how they can make our jobs more delightful.

Comparative Ruby

For some of us, Ruby was our first programming language. Others of us have worked in software for many years before discovering Ruby. But when it comes down to it, how does Ruby truly compare with (or fit in among) other languages? According to Matz, Ruby evolved from Perl, Smalltalk, and Lisp, and it has, in turn, influenced several other languages in the programming ecosystem. Talks in this track should explore the differences and similarities of Ruby and its design patterns with those of other languages. Possible themes to touch on would be the functional programming aspects of Ruby, the equivalent of Ruby tools like Rubygems in other languages, or the nitty-gritty differences among the various programming paradigms.

Life Beyond Bootcamps

Coding bootcamps are swelling the ranks of the Ruby community. How can we leverage the unique backgrounds and skillsets of code school grads to better our workplaces? What challenges do newly-minted junior devs face while navigating their way in an unfamiliar field? And how do you know when a bootcamp grad is no longer “junior”?

This track is meant to answer those questions, as well as provide tips and wisdom for code school alums on how to successfully transition into the software world. Talks can also offer advice for companies on how best to integrate this growing pool of new developers into their teams.

Testing

The testing discussion burns bright in Ruby. We’ve moved well beyond the basics: the what and how of things like TDD, and many of the more foundational techniques. So, for our testing track this year, we’d like to hear the more nuanced, subtle discussions. Possible topics include explorations of newer testing techniques, how your testing practice has evolved over the years, or even what testing fundamentals you’d burn down given the chance. Our aim is for talks in this track to advance the discourse around testing in Ruby or change the boundaries of that conversation.

Weird Ruby

Ever since Ruby was but a small pup under Matz’s care, it has been finding its way into the most curious of places. As a community, we’ve always embraced the whimsy of Ruby, and sometimes that very whimsy is what has pushed mere experiments to become game-changing products. In this track, we want to hear about all the weird and wonderful things you use Ruby for. From odd problems to even stranger projects, let’s see what you’ve got!

Ruby Deep Dive

When you peek under the hood of Ruby’s shiny API, there are many fascinating techniques and tricks used to make developers’ lives much easier. In this track, we want to see talks about those nitty-gritty details of Ruby: method caches, object alignments, string encodings, etc. Come help shed a light on how Ruby is implemented!

Lessons Learned

On the journey from greenhorn to project lead, there are a near-infinite number of decisions to make, and often not much in the way of a roadmap for avoiding costly mistakes. While having fundamentals and basic principles under our belt is all well and good, there are some lessons only experience can teach us on how to work effectively, both solo and as a team. Talks in this track should discuss the lessons learned as people begin leveling up and coming into their own as software developers.

Ruby And Hardware

Come show us the awesome things you’ve made blink, fly, or maybe just open with Ruby!

Distributed Systems

Ruby is now just one tool in a developer's workshop. How we wire all those services together and manage them continues to be a huge topic in software today. In this track, we want to hear about how you’re using Ruby services in a distributed nature.

Performance

Last year, Matz put forth an ambitious goal: Make Ruby 3x faster. The obvious question is -- how? As Rubyists, we’re always looking to make Ruby go faster and do more with less, and we want to hear your strategies. Topics in this track could include: applying tweaks to application code, the best core methods for your performance needs, or low-level optimizations inside Ruby implementations. If it makes Ruby perform better, it’s fair game.

War Stories - Your Worst Day

Did a bug you pushed to production take down an entire website? Did an oversight in your feature result in thousands -- maybe even millions -- of lost revenue? This track’s talks will focus on laughing at the mistakes we first cried about; the times we were roused at 3am by that dreaded pager call; and how we learned and changed our development, management, or team processes to better handle those situations. On days when you feel like your code is a giant dumpster fire, it is sometimes comforting to know that at some point, somewhere out there, someone has dealt with (and fixed!) fires that were far worse.

About the Review Process

Proposals will go through two rounds of evaluation. The first round review will be blind — reviewers do not have access to your information, only what is in your proposal, to keep basic biases out of our calculations. Please respect this process by keeping your biographical information out of the proposal itself.

In the second round, proposals that have cleared the first round will be reviewed along with your information. The purpose of this round is to evaluate proposals alongside your past speaking experience, relevant credentials, and anything else that you provide that would help our committee see what a great job you'll do. The program committee is heavily committed to selecting a diverse and well-qualified group of speakers.

During the first round, program committee members may have questions and feedback for you about your proposal. The CFP application allows for two-way correspondence without revealing speaker identities. You'll receive an email notification when a reviewer leaves feedback for you. Please reply promptly and consider adjustments when requested. Our committee will have hundreds of proposals to look over, so you'll want to be sure that you're not a process blocker.

Every proposal submission will be responded to, whether or not the talk is accepted. Please only contact us with questions on this if you have not heard back by September 21.

What You Get

Speakers at RubyConf receive free admission to the conference, as well as the respect and adulation of their peers. As noted, for new speakers, we're also more than happy to help with your prep however we can; we want RubyConf to be as enjoyable for our speakers as it is for our attendees. Request assistance, talk reviews, check-ins, etc. via email to rubyconf@rubycentral.org.

Whether or not your talk is accepted, if you submit a proposal, we'll reserve a ticket space for you. So even if the conference sells out and your proposal isn't accepted, you'll still have the chance to buy a RubyConf ticket. Instructions on how to do so will be in the email that we send to you.