Thank you for your interest in speaking at RailsConf 2016! This year’s conference will be from May 4-6 in Kansas City, Missouri, in the USA. We're looking forward to seeing all your proposals!
Please read these guidelines all the way through for the best chance of having your proposal selected. If you have questions or concerns about anything you see here, please don’t hesitate to email us at email@example.com.
We will be doing "rolling acceptances," so submit early, and your talk may be accepted early!
If you have not heard about the status of your submission after that time, please contact us. Thanks!
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 firstname.lastname@example.org with any questions. (note: the link currently leads to the 2015 policy, but it holds true for RailsConf 2016 as well.)
Regular talks are 45-minute blocks, including any Q&A you want to do.
Workshops are 90 minutes to 3 hours long. You'll find some special information about workshops in the Track Guidelines section below. Please be sure to read all that stuff before you submit a workshop.
If your session is selected for inclusion in our program, you get:
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.
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.
In speakers: a diverse and creative line-up of speakers with a range of experience levels (in Ruby, in programming, and in public speaking).
In talks and workshops: a range of topics, both occupational (i.e., about Rails, code-heavy, etc.) and organizational (i.e., about team dynamics, communication, etc.), and all applicable hybrids. We want talks aimed at developers coming from a wide range of experience levels, from beginner-friendly how-tos to cautionary tales to deep dives for experienced devs. We want talks about all the different parts of the Rails ecosystem, including related technologies (data stores, front-end frameworks) and related teams (QA, product management, clients).
In addition to our general sessions, we seek proposals for a number of more narrowly-focused tracks. Tracks are narrative-driven blocks of 3-6 talks that are presented sequentially in the same room on the same day.
About half the selected sessions, overall, will be on a track. The rest will be in the general program. All talks will be considered for the general program. If you want your proposal to also be considered for a track, please tag it with that track when you submit it.
Here are our tracks for this year:
Rails is the dominant web framework in Ruby, but these days we have so many alternatives to choose from, all with different goals and approaches. Talks in this track will explore the current landscape of Rails alternatives, specifically introducing the alternative, demonstrating how it's different, and explaining why you would use it. We'd love talks on Ruby-based frameworks, and we'll also consider non-Ruby alternatives. Frameworks that are at least a little bit practical will have the edge.
The app pendulum swings wide: on one end is brand new, fresh apps with little to no traffic; on the other end, established apps at scale. However, a lot of apps live in between those two extremes. This track is about the apps in the middle: where the team may number fewer than a dozen and while practices may not be bad, they also may not yet be great. Talks might touch on topics such as the dynamics of a small(ish) team, tools for growth when there aren't limitless resources, how to optimize code quality without a lot of people or time, etc.... let's hear about how, when working on the apps in the middle, you make the best with what you have.
The Rails code that you write is only one part of a successful project. To achieve success, you additionally have to do so many other things: gather requirements, estimate and measure progress, handle team dynamics, track bugs, keep stakeholders informed, and many more. Talks in this track will discuss how these things come together to form a successful Rails team.
Rails is a framework optimized for programmer happiness and sustainable productivity. While this is great for productivity, it is also be a source of confusion, especially for folks new to the framework, the language, or web development in general. Over time, this has earned Rails the reputation of being "full of magic." This track is dedicated to helping our attendees go deeper and gain a better understanding of the magic, by diving into the internals of Rails (or other gems like devise). Potential topics include: what is a
Concern? What does
1.day.ago actually do? How are Ruby modules used inside Rails? How does the Rails router (or Active Record query API, simple form, RSpec, etc.) DSL work? What about the HTTP protocol - how does that tie into the Rack/Rails architecture? How do devise, omniauth, etc., tie themselves into Rails?
One of our greatest strengths is our vibrant ecosystem. Whatever the task at hand, there is probably a gem (or multiple!) to help you. This track will feature talks about contributing to the Ruby and Rails ecosystem and our wider open source community. Possible topics include: what's the best way to get started? Where do you find inspirations and ideas for new projects? What are the tools/tricks you use? What makes a successful open-source project, and what are your tactics for growing (and maintaining) a healthy community around your project? What are the challenges you face as a maintainer, and how can we help?
We've heard a lot about front-end frameworks, but how often do we hear about the process of design, and how that moves into feature development? This track is not for designers alone, but for designers and engineers alike. Talks will cover the tools, processes, and patterns needed to optimize the designer/developer relationship -- so we can build better and more cohesive products together.
Interviewing developers is hard to get right. It's time-consuming, evaluations are subjective, and our biases are built-in, subtle, and hard to correct for. And perhaps even more difficult than hiring is retention. A particular challenge when working to hire a diverse team of people (some of whom are motivated by different aspects of work than you are) is figuring out how to give every team member the best chance of success. How do you notice problems? How do you help solve them? How do you give developers opportunities to grow, even at a small company? How do you keep experienced engineers interested and engaged as they grow their skills? Talks in this track will address all aspects of hiring, interviewing, managing, and retaining technical staff. Specifically, we'd love for talks to include case studies, recommendations, surveys, and research.
For numerous reasons, an increasing number of companies are writing a collection of distributed systems when creating full-fledged web applications. It’s become more and more rare for a Rails application to cover the complete stack. This track will feature talks about building distributed systems around Rails, as well as what the rest of the stack in the system looks like.
The Rails Security team goes to great efforts to make all of our applications safe. At the same time, many of us don't know how to prevent our applications from being the lowest hanging fruit for an attack, or what can we do to stay ahead of potential attackers. This track will feature talks explaining what Rails (and possibly popular gems) do to prevent our applications from being compromised, as well as talks covering the (good) practices we should all follow to make our applications more secure.
Rails 5.0 is just around the corner and many of us are excited to learn about all the shiny new features and any behind-the-scenes improvements. If you have worked on or experimented with these features extensively, we would love to hear from you! Talks in this track will go beyond what is in the release notes and dive deeper into these new features, including specific focuses on their implementation or real-world experiences of using them.
This track will focus on Rails projects that "do good," specifically featuring talks on projects tackling social issues such as homelessness, education, civic engagement, and housing. Oftentimes, a unique characteristic of working on civic tech projects is dealing with the government or non-profits, who aren't always the most technical or innovative. This track's talks will discuss how "doing good" may influence an app's building or implementation, and what obstacles or surprises might have been faced in the attempt to use Rails for good.
While RailsConf has featured Beginner tracks in the past, this is specifically a track for and by Junior Developers! Talks in this track will cover technical topics that are accessible at a junior level and introductory-level concepts about Rails, but will also touch on specific issues around learning and working as a Junior Developer.
Developers aren't always the best at navigating their own tech careers. Evaluating a new offer, knowing how to navigate a new office environment, and leveling up on the job are all important aspects of building a long-term tech career that we don't often discuss. Talks in this track will advise on how to build the career that you want, from your first junior web developer role to potentially being a CTO. Possible topics include salary negotiating, work-life balance, navigating office politics, finding a new job, examining different career paths/options, and managing up.
It can be difficult to connect the dots between what you learn at a conference and practical application. The Workshop track will bridge that gap with hands-on practice and learning. Sessions will focus on practical topics such as building Rails apps from scratch, refactoring, testing untested apps, building APIs, decoupling components, and complementary technologies/techniques found in the Rails ecosystem, among other topics!
In particular, we encourage workshops that overlap with the themes from our other tracks -- if attendees who just learned something on one track can come practice it on the Workshop track, everybody wins!
Unlike all other talks, workshops can vary in length: anywhere from 90 minutes up to 3 hours. So, in your proposal, please be detailed about the material you plan to cover (including hands-on material/exercises), the length you'd plan for the workshop being, and who will be assisting you with the workshop.
That's it! Don't forget that we are also looking for talks of interest to Rails developers that aren't included in the track list above. So don't let lack of a relevant track stop you from sending in a proposal!
Thank you for making it this far. :) We will be receiving hundreds of proposals, many of which cover the same topics. Read the following to help you craft a proposal that stands out.
Start with a topic of interest to attendees. Our attendees are generally Rails developers at many different levels of experience, from totally new to very experienced. Your talk should either directly help them or inspire/inform them about something they don't already know. The core value to our attendees of what you're presenting should be clearly stated in your proposal. What will they be able to do after they see your talk that they can't do now?
Our proposal form has two fields that attendees will see on the program (Title and Abstract), and two fields that only our reviewers will see (Details and Pitch). Here are a few more details on each of those.
These are what attendees will see in the program. Thus, your Title and Abstract should be compelling and to-the-point. Tell a story. Why should attendees come to your talk and what will they get out of it?
Details is a good place to go into more depth about what you'll cover. This is where you might put an outline, reveal the secret sauce, and explain any twists you would include in your talk that may not be evident in the Title or Abstract.
Pitch, on the other hand, is where you tell reviewers why RailsConf needs this talk, and why you're the right person to give the talk. How will your talk help the RailsConf program, or fill a specific need? Why are you excited about this topic? Please take extra care here to refrain from identifying who you are. As mentioned above, our first round of review is blind, and we appreciate your efforts to respect that.