Thank you for your interest in speaking at RailsConf 2015! This year’s conference will be from April 21-23 in Atlanta, Georgia, USA. We are very excited to read all of your proposals, but first wanted to share a few guidelines that will give you the best chance of having your proposal accepted. If you have any questions about these guidelines, don’t hesitate to email us at email@example.com.
Proposals can be submitted until February 6, 2015 at 11:59pm EST. However, we will be reviewing and accepting talks on a rolling basis, so the earlier you submit, the better your odds. Our aim is to have the complete program announced by February 24. Note: every proposal submission will be responded to by March 3, whether or not your talk has been accepted. Please ONLY contact us with questions on this if you have not heard back by March 3.
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! Keep reading for more info on how to submit a terrific proposal using our process.
Along with general sessions, some of our accepted talks will be part of themed tracks. Each track is curated by a Track Director and should follow additional guidelines listed below to make sure they are on topic. Please scroll down to read the details of each track's guidelines. If you want your proposal to be considered for a track, please tag it with the Track(s) that you find most fitting.
Since over half the program will not be part of a track, you do not need to limit your proposal’s topic to the listed tracks. When in doubt, do submit your talk even if you feel it may not be on topic -- don’t forget, we can’t accept a talk that we never see!
Regular talks are 45-minute blocks. We recommend 30-35 minutes of presentation, followed by allowing 10-15 minutes for questions and discussion. Lab sessions can vary from 90 minutes to 3 hours, so if you are submitting a Lab proposal, please note the proposed length within your submission.
Speakers at RailsConf receive free admission to the conference, a $500 (USD) honorarium (sent post-RailsConf), and of course, the respect and adulation of their peers. As noted, for new speakers, we're also more than happy to help you with your prep in any way that we can; we want RailsConf to be as enjoyable for our speakers as it is for our attendees. Assistance can be requested via email to firstname.lastname@example.org.
If you submit a proposal, whether or not it’s accepted, we will reserve a ticket space for you for a period of time (through March 20). That means that if you're waiting to find out if your proposal has been accepted before buying a ticket, don’t worry, and don’t spend your money yet. Just submitting a proposal means that even if the conference sells out and your talk isn't accepted, you'll still have the chance to buy a RailsConf ticket. We've got your back.
A lot of people these days are using Rails to build both their internal and external APIs. How do you or does your company go about building APIs in Rails? What are some lessons and best practices that you have learned? How do you use it on the client side? Come share everything you know about writing awesome APIs in Rails.
The Beginner track is meant for those new to Rails! We're looking for talks that help Rails newcomers get started in the right direction. This is the track for sharing stories and advice about topics such as: what most excites or disappoints you about working with Rails, best practices when working with Rails, and any personal stories you may have that would benefit the next generation of Rails programmers.
Extreme Programming, Software Craftsmanship, Software Carpentry, and other related movements over the years have all explored the craft of how we develop software and how it can make a difference. This track will give those voices a stage, and is for those interested in taking their craft of programming to the next level.
What are our values as developers? How do we express these values in our work, in our teams, and in our jobs? This track focuses on important non-technical aspects of being a developer, and includes topics ranging from diversity to happiness, team dynamics to company culture. Let's explore how we can make a positive impact in our workplace and our community.
Many of our applications these days have a bigger emphasis than in years past on the data we gather, store, warehouse, analyze, and present. Talks in this track will focus on how data flows through your organization and the tools you use to manage that.
It has become increasingly rare for a Rails application to be the only service written when creating a full-fledged web application. Gone are the days of a Rails app only talking to a database to do all its work. Instead, these days, an increasing number of companies are writing a collection of distributed systems to help isolate work. This track will explore how we as a community do that.
As developers, if we're not constantly learning and growing, we're losing ground. And if we're not attracting smart, capable people to our field, we're missing out on opportunities to get better. So what can we do to educate and attract new people, help existing developers level up, and retain and grow senior engineers? Talks in this track will focus on recruiting, education, training, mentoring, and creating a culture that values learning and growth.
It can be difficult to connect the dots between what you learn at a conference and practical application. In the Labs track we'll focus on hands-on practice. Building Rails apps from scratch, refactoring, testing untested apps, building APIs, decoupling components, etc. We encourage the submission of Labs that overlap with the themes from our other tracks (if attendees who just learned about something in one track can come practice it within the Labs track, everybody wins!), but this is not a requirement. Lab sessions can vary in length from 90 minutes up to 3 hours. Please let us know how long your Lab session would run.
In this track, we’re looking to showcase case studies of real-world companies using Rails in interesting and compelling ways. Large deployments, hard problems solved, and lessons learned provide valuable insight to the community and our attendees. We want to hear your war stories!
Testing has been a first-class citizen in Rails and its community since the beginning. Talks in this track will highlight the various approaches and styles of testing within Rails, and can include topics such as gems/tools, techniques, or approaches.
We will be receiving hundreds of proposals, many covering the same topics. Knowing what makes a good talk and what helps you best stand out amidst the other proposals competing for fewer than 80 spots is important.
Start with a topic that is of interest to attendees. The tracks listed above will guide you towards what we think attendees will enjoy. Your talk should either directly help attendees or inspire/inform them about something they don't already know. It should be more than you 'reading out loud' a blog post on how to use a particular gem. We have a special affinity for talks that spark conversation or move the audience to take action. It’s fine if your talk doesn't aspire to change the hearts and minds of your audience, but the core value to our attendees of what you're presenting should be clearly stated in your proposal.
The Abstract field is where you write a short paragraph to quickly tell us what you're going to talk about. This gets published in the program along with the title, so it is the public face of your talk. Your 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?
The Details field is for you to go into more depth to us about what you’ll cover. Only reviewers can see it, so it's a good place for things that shouldn't be revealed in the abstract. This is where you can show the Program Committee what you plan to cover, and how you plan to do it. This would be the place to reveal an outline of your content, the content of your secret sauce, or the twist you’ll include to impress the audience.
The Pitch field is your chance to show the reviewers why you should be giving this talk at RailsConf. Here is the place to focus on how your talk will help the program, or fill a specific need. Explain why you're passionate about this topic. In this area specifically, please take extra care to refrain from identifying who you are, if you can help it. We understand that it may be most difficult in this section, but we appreciate your efforts at respecting our blind review, as explained below.
Proposals will go through two rounds of evaluation. The first round review will be blind — reviewers do not have access to your biographical 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 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 for you about your proposal. The CFP application allows for two-way correspondence without revealing speaker identities. You'll receive an email notification if there are questions 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 blocker.
Above all: thank you for submitting your proposal(s) to RailsConf 2015, and good luck!