RailsConf 2017 CFP

Thank you for your interest in speaking at RailsConf 2017! This year’s conference will be from April 25-27 in Phoenix, Arizona. We're looking forward to seeing all of your proposals!

Please read these guidelines all the way through for the best chances of having your proposal selected. If you have questions or concerns about anything you see here, please don’t hesitate to email us at railsconf@rubycentral.org.

Important Dates

1. This call for proposals (CFP) closes on January 20th, 2017, 11:59pm MST. (Note: we always tack this deadline to the conference location’s timezone. This deadline is also 10:59pm PST / 1:59am (January 21) EST .) We will be doing "rolling acceptances," so submit early, and your talk may be accepted early!

2. You will hear from us on or before February 14th, 2017. If you have not heard about the status of your submission after that time, please contact us. Thanks!

Important Baseline

All talks and speakers must comply wholly with our Anti-Harassment Policy, which applies in all RailsConf-related communications as well as at the conference itself. Please review it before submitting your proposal, and email us at railsconf@rubycentral.org with any questions.

What We're Looking For

RailsConf is a three-day conference with up to seven sessions running concurrently. We will probably end up accepting around 80 proposals. Given that, we’re looking for technical and non-technical talks covering a broad range of topics in the Rails ecosystem. Our audience members are Ruby on Rails developers, QA folks, designers, former-developers-turned-managers, and many more, with experience levels ranging from beginner to veteran.

We want a mix of beginner, intermediate and advanced-level material. Overall, we are looking for talks of interest to Rails developers, and we take a pretty broad view of what that means. If it’s interesting to you, chances are we’d love to see it. For a look at previous accepted talks, you can check out the 2016 RailsConf program.

In addition to our general program, we seek proposals for a number of more narrowly-focused tracks, which are narrative-driven blocks of ~3 sessions presented sequentially in the same room. Specific topics vary from year to year and reflect the particular interests of this year’s Program Committee. Below, you can see the specific tracks we are looking for, with descriptions of what sort of content would fit in those tracks. If you have a great session idea for one or more of those tracks, please select that when you submit it; otherwise, opt to submit your proposal for contention in the general program. When the Program Committee is reviewing proposals, they reserve the right to “re-track” talks (or move them into the general program) as appropriate, but your selection while submitting does help us with our initial track sorting.

RailsConf fully embraces both new and experienced speakers. We place a strong value on featuring a diverse, creative line-up of speakers: ones from different backgrounds with a wealth of different experiences to share with our attendees.

Session Formats

When submitting a proposal, you'll need to select one of three formats.

The regular session format is for 40-minute lecture-style presentations (that time includes any Q&A you may want to do).

The panel session format is also 40 minutes long. Instead of a single speaker presenting information, the panel is moderated by the proposal submitter, has a list of panelists (4 maximum), and covers a specific topic.

The workshop session format is an interactive format of at least 90 minutes in length. The focus of a workshop is on attendees learning practical skills, through a mix of presentation material and hands-on exercises. Workshop topics mirror the program sessions from both general and individual tracks.

Speaker Benefits

If your session is selected for inclusion in our program, you get:

• Free admission to the conference.
• A $500 USD travel reimbursement honorarium, sent to you post-RailsConf. Note: for panels and regular sessions with more than one speaker, this honorarium is to be split among all participants, at the panel moderator or speakers' discretion
• The respect and adulation of your peers!
• The opportunity to be paired with a speaker mentor before the conference to help you with talk prep. This will be automatic if you're a new speaker, optional for experienced speakers, and highly recommended for everyone.

We reserve ticket space for folks whose talks are not accepted, so you can wait on buying a ticket until you hear about the status of your talk.

Inside the Review Process

We have a Program Committee made up of hardworking volunteers representing a variety of experience levels with Rails. Our first round of review is blind, meaning reviewers will not see your name or biographical information. They will see the title, description, pitch, and abstract. Please keep any potentially identifying information out of these fields.

During this first round, reviewers may have questions for you about your proposal. The CFP application allows two-way correspondence in comments without revealing your identity (though you'll know who's asking the question). You'll get an email (and see a notification on the site) if there are questions for you. Please reply promptly and consider adjustments, if requested.

Once every talk has at least three ratings, we move into the second round, where we evaluate highly-rated talks alongside their biographical information (speaking experience, relevant credentials, etc.) to come up with a balanced program. The Program Committee is heavily committed to selecting a diverse and well-qualified group of speakers.

Track Guidelines

Code Organization

When a codebase starts outgrowing the basic Rails conventions for code organization, what should you do? You can't just keep adding code to user.rb forever. Or...can you? Jobs, Presenters, Decorators, all of the above? For this track, we'd like to hear proposals on your approaches to code organization inside a large Rails codebase -- before you start thinking about services. We're looking for real-world case studies rather than prescriptive talks that advocate a particular scheme. Tell us about both the benefits of your method and its drawbacks.

Developer Happiness

You want to be able to do the best job you can, and doing so requires a certain state of mind. What that state is and what enables us to get there is different for all of us. Maybe what’s important to you is working remotely while traveling the world, or teaching kids how to code, or maintaining your physical well-being, or building a company, or dealing with addiction or other mental health issues, or driving a race car... or maybe it’s something totally different. Whatever it is, we want to hear proposals on what keeps – or is going to make – you happy inside and outside of work. The only constraints are that proposals are based on a speaker’s personal experiences and contain something others can learn from (with a caveat that “recipes for happiness” don’t work universally for all people). Potential takeaways for attendees are practical tips & tricks or a greater awareness of how to foster more developer happiness.

Distributed Teams

Some teams start out fully distributed, while others start out fully on-site. In the last few years, we've seen each type start to adopt some of the practices of the other as companies both try to take advantage of high-bandwidth in-person communication as well as attract developers who live in different cities, different time zones, and even different countries. How has your team moved towards (or away from) being fully distributed? How has it affected how you manage the team? How has it affected the code? For this track, we want to hear proposals on various experiences in this quickly evolving landscape.

High Volume

Sometimes things get busy on the web. Really, really busy. Whether it's analytics, Black Friday sales, or streaming "All I Want for Christmas" on December 25th: clusters of servers are handling tens or hundreds of thousands of requests per second in real-time. We'd love to hear proposals on how to handle huge amounts of (peak) traffic: nifty workarounds & shortcuts you've come up with, how to keep data in sync during rush hour, edge cases, and of course, horror stories from the trenches. We're less interested in scripts to automatically spin up more dynos.

Leading at All Levels

What does the word "leadership" even mean? For this not-just-for-managers track, we are looking for proposals on what improving leadership skills can mean for a developer or a team and how it can be applied to every level. There are lots of ways to lead in tech... as a manager, peer mentor, teacher, or just someone who stepped up to fill a gap. Becoming a leader doesn't just happen at one point in a developer's career, and it isn't learned all at once. Talks in this track can cover subjects like: training the trainers, leveling up a team or yourself, mentorship, and effective team gatherings or retreats.

Machine Learning

There's no denying that in our near-future of self-driving cars, computers that we talk to with natural language via voice or text, and bots that recommend the next açai bowl place we should check out, we need to pay attention to machine learning. This track is open to any talks about data science, artificial intelligence, and machine learning. The talks don't have to use Ruby, but they should be aimed at a Ruby audience.

Open Source Deep Dive

Ruby and Rails are known for optimizing for developer happiness and productivity. But how do these tools actually work? With this track, we’re seeking proposals that look at the internals of Rails or other open source gems. Topics could include things like: How does Active Record's type casting work? What happens inside RSpec's predicate builder? How do gems support both Minitest and RSpec? While learning for the sake of learning can be fun, preference will be given to proposals which demonstrate how the knowledge gained will be relevant to the audience.

Panels! Panels! Panels!

While conference talks are great, this track is all panels, all the time. A panel of individuals can often provide diverse perspectives on an issue or topic. In this track, we want to see abstracts that offer the audience a variety of opinions in one session. Abstracts could include anything from perspectives on a certain technology or development pattern to effective onboarding techniques to engineering team cultures. Because this is a unique type of session, we wanted to provide some additional parameters: if you are submitting the abstract, you are expected to moderate the panel. Panels can have anywhere from 2-4 panelists (not including the moderator). ALL participants, meaning the moderator and all panelists, will receive a complimentary speaker's pass to RailsConf 2017. For these submissions, while you don't need to have all panelists confirmed, we would like to see at least one or two confirmed panelists and a description of the types of people you hope to confirm before the conference.

Unconventional Rails

Rails is an 800-lb gorilla in the request/response web application space but has wider capabilities with ActionMailer, ActionCable, ActiveJob and the new API mode. Have you expanded Rails into an unconventional area? This track is for proposals that tell us that story, as well as: How did you implement it? What did you learn?

Thanks for submitting a proposal to RailsConf 2017!

Good luck!