RailsConf 2018 CFP

Thank you for your interest in speaking at RailsConf 2018! This year’s conference will be from April 17-19 in Pittsburgh, Pennsylvania. 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 19th, 2018, 11:59pm EST. (Note: we always tack this deadline to the conference location’s timezone. This deadline is also 8:59pm PST .) 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 9th, 2018. 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 2017 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-6 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:

1. Free admission to the conference (for up to two speakers and four panelists).
2. 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
3. The respect and adulation of your peers!
4. The opportunity to be paired with a speaker mentor before the conference to help you with talk prep. Mentors are granted upon request, but highly recommended, especially for new speakers.

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 highly-rated talks are evaluated 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

Business and Rails

A business is just a vehicle for a good idea. Rails is a fast way of expressing your good ideas on the web. It seems inevitable that these two meet. This track is for those talks about the world of SaaS, customers, support, hiring, and all that “business” stuff that lets us build the Rails apps we love working in. Tell us everything you think a Rails developer should know about the businesses that inevitably surround them.

Deploying and Running Rails

If a Rails app only runs in development, does it make a sound? Success for your app is having people use it, and that means production in some form. Talks in this track should tell us all about how you make that happen. Whether it’s orchestration frameworks like Kubernetes, modern Capistrano, or fault monitoring to make sure it still works, tell us how you do it!

Evolving Talent

It’s believed that the number of software developers in the industry is doubling every five years. Every company wants to hire for experience, but there’s a competitive advantage in the ability to evolve talent. Talks in this track should discuss how we grow responsibly by allowing individuals to advance and teams to thrive. Ideally, this track will contain deeper dives beyond “hire juniors, you’ll survive and they’re nice people” or “have mentorship.” Assuming that the audience is already in favor of growing people, talks should focus on best practices for making it happen.

How It Works

Rails abstractions are powerful, but how do things actually work under the hood? Talks in this track will examine some of the features we take for granted. Assuming the audience is familiar with Rails-style usage, but have seldom had to dig deeper, talks should provide a deeper understanding of the technology to help them build and debug better. Topics might include how HTTP requests become Rails controller actions or deep dives into ActiveRecord database adapters.

Modern Javascript in Rails

Ignoring Javascript is hard. Luckily, the addition of Rails Webpacker makes it easy to introduce modern Javascript into your Rails application. 

But how do you set that up? What even is Webpack? Or say you've got it set up... now what? What is ES6? Babel, React, Vue, what are these things? How is this new era of Javascript any different from the Asset Pipeline and using CoffeeScript?

This track's aim is to help others learn how to setup and start utilizing modern Javascript in their Rails applications. Talks in this track should help showcase modern-day Javascript and show how to use it within the context of Rails. 

Rails and Services

Service-oriented architecture and microservices continue to be a common architectural pattern in 2018, one that more and more companies are migrating their application environments towards. Rails is a flexible player in this environment, able to be a front-end application, a middleware API, or back-end coordination layer -- and sometimes all 3 at once! Talks in this track can address questions such as: What are the patterns that you’re discovering (technical and organizational) and how does Rails fit into your larger architecture? How have you leveraged Rails' existing benefits, or extended it to serve these environments? What lessons have you learned about consuming external services into a typical Rails stack?

Reconsidering the Basics

Rails emerged as a way to save developers time by making opinionated choices about how to best accomplish common tasks related to building web applications. The success of Rails has elevated practical solutions to developer problems, ultimately saving countless hours and endless headaches.

However, its success simultaneously entrenched Rails technologies and solutions into our workflow, leading to a constellation of tools and solutions that together we sometimes refer to as “The Rails Way.” As these tools became more successful, they tended to slow progress, as project focuses shifted from feature development to support; it can be risky to experiment with a new paradigm or approach when your library is used by a majority of Rails applications!

That doesn’t mean though that new technologies and paradigms aren’t out there, waiting to be discovered and evangelized. Talks in this track should address these issues, bringing us back to basics from new approaches, solving old problems with fresh ideas.

Testing out of the Box

Automated testing has long been a core part of the Rails philosophy. Starting way back with 1.0, we’ve emphasized testing to a degree not found in other communities. For this track, we want to take it one..step…BEYOND. Talks in this track should tell us how you use tests beyond verifying basic code and interface use. Are you testing accessibility? Verifying third-party APIs? Something even more out-of-the-box? This is the track for you.

The History of Rails

Ruby on Rails was revolutionary. It helped shape the evolution of the internet over the past 11+ years. However, that doesn't mean that Rails hasn't seen changes and improvements along the way.

Were you around for that revolution or do you have an excellent knowledge of the history of Rails? Talks in this track are an opportunity to help remind seasoned Rails developers of the "old" days and teach new developers our history. Possible topics include the web before Rails, stories of upgrading Rails 1 and Rails 2 apps, or Merb and its merge into Rails.

Unusual Rails Apps

Rails has come a long way since its early days of being used primarily for blogs and other CRUD apps. Nowadays, some people are breaking the mold and using Rails in much weirder and more creative ways. Whether you're using Rails to run a nuclear weapons silo or to run your smart house, talks in this track will focus on the unusual ways you’ve used Rails and the unusual places it’s found.

When It All Goes Wrong

All software has bugs and all developers spend time debugging. Whether you use Pry, print statements, or “push and pray,” everyone has tactics they use to find and discover bugs. Talks in this track could include deep dives into your favorite debugging tools and techniques, war stories of debugging nightmares and how you solved them, or tips for improving our debugging processes.

Thanks for submitting a proposal and good luck!