Thank you for your interest in speaking at RailsConf 2014! The conference this year is April 22-25 in Chicago, Illinois, 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 firstname.lastname@example.org.
You can submit a proposal until February 21st, 2014 at 11:59pm CST. We'll be 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 March 7th. 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 getting started and getting noticed.
This year, we've evolved our process a bit to include themed Tracks. Our goal is a significantly more diverse program, with talks aimed at different skill levels as well as different topics.
Each Track has a Conductor (ha ha, get it?) who is responsible for selecting relevant talks. Some Tracks will be longer, others shorter; the pool of proposals will help us make those decisions. Each Conductor has written some additional guidelines for their track; you can find those below. When you submit your talk, please tag it with the Track(s) that you find most fitting. Note: there WILL also be untracked talks, so if your talk doesn't fit in any of them, please still submit it!
We require all selected talks to comply wholly with our Anti-Harassment Policy. If you have any questions about this, or other parts of these guidelines, don't hesitate to ask us at email@example.com.
Regular talks are 45-minute blocks. We recommend 30-35 minutes of presentation, followed by 10-15 minutes of questions and discussion. Workshop sessions can vary from this length, so if you are submitting a workshop proposal, please note the proposed length in your proposal. For certain other tracks, we may suggest a different usage of the 45-minute block; when applicable, this will be communicated in the review process.
We will be receiving hundreds of proposals, many covering the same topic. 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 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’s 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 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.
We'll be accepting talks on a rolling basis—one batch in late January, another in mid-February. Note: if your proposal is not accepted the first time around, you may still get in on the second pass.
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 March 8th.
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 with your prep however 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.
Whether or not your talk is accepted, if you submit a proposal, we'll reserve a ticket space for you. That means that if you're waiting to purchase a spot just in case your proposal is accepted, you don't need to worry. Even if the conference sells out and your proposals aren't accepted, you'll still have the chance to buy a RailsConf ticket. We've got your back.
As many as one-third of RailsConf attendees are first-timers. What do you wish somebody had told you when you were starting with Rails? What parts of Rails do you think are insufficiently documented, or overly dependent on lore passed from person to person? What most excites you about working with Rails? Successful novice track talks cover topics of interest to new Rails programmers, but aren't necessarily simplistic.
This track is all about automated testing and how it intersects with Rails. We're particularly interested in talks about using tests to drive the structure and design of your code and talks about the practical uses of testing for parts of Rails applications that have the reputation of being hard to test. Other ideas include proposals for talks about new testing tools, or about managing large tested applications.
Our codebases and teams are growing, which presents a new set of challenges to the process of Rails development. For this track, we're interested in talks addressing the technical and social issues of a large and/or growing development project. At what point do we outgrow Rails conventional wisdom? Specific topics within this track could include application & OO design, modularity, services, splitting teams & code, management, or developer specialization.
A Rails app in the wild includes so much more than Rails -- generally, at a minimum, you'll find some key-value stores, some load balancers, centralized logging, and of course, some way to update all of that in a sane way. For this track, we'd like to see talks about the intersection of Rails and its larger web-app ecosystem. Topics could include app deployment, network & system design, configuration management, or the integration (or separation) of operations & everyday development.
Rails, much like Ruby, borrows good ideas from many different areas. This track is looking for talks to answer questions like the following: What good ideas is Rails missing? How can we learn from other frameworks and languages? How can you show attendees the way forward in Rails with a new idea? What changes can Rails make to handle approaches found in other frameworks?
This track is for folks who like to show rather than tell. Sure, we’re looking for talks, but we really want to see you writing, refactoring, or showing off code, right in your editor. Do you dare build something live on stage? Those who rise to this challenge will likely find themselves with captivated audiences. In this track, static slides are disallowed.
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’d love to hear your war stories!
As so many of you already know, there are hugely important parts of our jobs as Rails developers that do not concern coding at all. For this track, we’re interested in talks covering topics outside of coding. Specific topics within this track could include developer happiness, successful working environments, working with others, project management, diversity, or community building.
As developers, there are many things we can learn from ideas and concepts already known in the visual design community. This track aims to give designers the stage, in order to share this wisdom. Our goal is not to make attendees designers, but we are looking for talks to give Rails developers new skills and perspectives to complement or improve how we build software.
It’s become more and more 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 small services to help isolate work. This track will explore how we as a community do that. Specific topics in this track could include how services find each other or how databases can help you scale. Come tell us your take on the wild world of Service Oriented Architecture!
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, for those interested in taking their craft of programming to the next level.
During the conference, we run a dedicated workshop track. Workshop topics can cover beginning, intermediate, or advanced concepts. Unlike talks in the other RailsConf tracks, workshops will vary in length based on topic, and so are not constrained to 45 minutes. The basic requirements of a workshop are that it’s both hands-on and specific in what it will teach. Topics within the workshop track could run the gamut, from ActiveRecord and other parts of the Rails stack to complementary technologies and techniques found in the Rails ecosystem (e.g. TDD, wireframing, engine authoring, api writing).