RubyConf 2018 CFP
- CFP closes:
- Jul 31, 2018 at 11:59pm PDT
- about 1 month left to submit your proposal
CFP Stats13 proposals
Thank you for your interest in speaking at RubyConf 2018! The conference is November 13-15, 2018 in Los Angeles, CA, USA.
Please read through and follow ALL guidelines below to boost your proposal’s chances of being accepted! If you have questions about any of these guidelines, you can reach us at email@example.com.
We'd love for you to come share your knowledge with ~800 of your closest colleagues & friends. We welcome all talks related to the Ruby programming language, from the mainstream and basic to the niche and obscure.
The only exception: if your talk is primarily about Ruby on Rails, then please don't submit it to RubyConf. Hold off and submit it to RailsConf in Spring 2019 instead. Thanks!
We require all selected talks to comply wholly with our Anti-Harassment Policy. If you have any questions about the suitability of your talk, or anything else in this CFP, email us at firstname.lastname@example.org.
Proposing a Talk
Talks should be 40 minutes long, which can include time for questions. If you want to take questions, we'd encourage you to plan for 30-35 minutes of presentation and to leave the rest of the time for questions. All talks should be lecture-style presentations.
Proposals can be submitted through July 31, 2018. We will be accepting talks on a rolling basis: the earlier you submit, the more likely you are to receive feedback on how to amend your proposal, which betters your ultimate odds of acceptance. Ultimately, our aim is to have every proposal responded to with an acceptance, waitlist, or decline by August 15, 2018.
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! If you want to learn more about how to improve your talk submission, this post and this one are good places to get started. Also, see the note about Speaker Mentors under "Speaker Benefits" below.
For more information on how RubyConf proposals are selected, read the "About the Review Process" below. If you have questions after that, we're happy to answer them or aid in other ways -- just let us know!
In addition to the general program, we also have a few themed tracks at RubyConf. These tracks have specific guidelines to describe the talks within them. Not every talk belongs in a track. If your proposal doesn't fit neatly in one of the below tracks, either tag it as General or don't tag it at all. However, if you do feel that your proposal might fit nicely within one of the below tracks, tag it with that track name.
Being a programmer means constantly making decisions: which structure to implement, which gem to install, or which project management tool to use. Often, these choices are important to our companies' bottom lines or to our codebase's future.
But sometimes, we're asked to make ethical decisions that underscore our foundational values. This track is for talks on the decisions you've made at work that may have kept you up at night. Talks might touch on the context that put you in that position, considerations to take into account, the decision you ultimately made and why, and how it all played out in the end.
When running software in production, stuff goes wrong, and it’s our job to fix it. Talks in this track will focus on those incident responses (IRs), including details on best practices, what to do after the fact, postmortems, learning reviews, and making production healthier.
What goes on behind the scenes when we run our Ruby programs? For a language that is such a joy to use, there must be a lot going on under the hood. Perhaps you’re curious about how tokenization and parsing work? Maybe you want to find out about Ruby’s virtual machine? And where does the C code come in? Talks in this track should explore these topics, with knowledge that can be applied to Ruby development and beyond, to other programming work as well.
If you've led an engineering team, you know there are countless different ways to lead, but also some commonalities among successful leaders. Talks in this track should focus on actionable ways to level up leadership skills or on how anyone on a team can take on a leadership role to help their whole team level up together. The ultimate goal of this track's talks is to help attendees work towards leading teams that make them as happy as their programming language makes them.
Make It Faster
Tell us your stories of optimization, in all of its forms. Talks in this track can focus on specifically making code run faster or more efficiently, but we'd also love to hear about other aspects of optimization. In addition to code, what other aspects of your job or workflow have you made faster? Detail for us how you made planning or putting together a project happen more quickly.
As important as it is to build scalable software, it's even more crucial to build scalable teams. If you've done this: how have you sustainably ramped up hiring and onboarding? How do you prevent knowledge silos amidst a growing team? When the whole team can't fit together in one room anymore, how do you scale communication practices? Talks in this track will detail how we can grow our organizations... while still putting people first.
No Ruby application is an island; each necessarily lives within a world of services. Whether it's utilizing services run as a SaaS, just talking to a database, or canoodling with other in-house programs, this is the way software is written now.
Talks in this track should focus on how to make using services more manageable. From how to use circuit breakers to protect SLA times to using a message queue that decouples services, we want to hear about your tools and/or the processes that keep you happy in this chaotic world.
About the Review Process
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 that 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 and feedback for you about your proposal. The CFP application allows for two-way correspondence without revealing speaker identities. You'll receive an email notification when a reviewer leaves feedback 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 process blocker.
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 August 15.
If your session is selected for inclusion in our program, you get:
- Free admission to the conference (for up to two Speakers).
- Invitation to our RubyConf 2018 Speaker Slack community, which can be a great resource as you're developing your talk.
- Invitation to a Speaker Dinner on the evening before the conference, where you can meet the other Speakers and staff before everything kicks off.
- 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.
Please note: we are not able to reimburse for Speaker travel or accommodation for RubyConf 2018.
Whether or not your talk is accepted, if you submit a proposal, we'll reserve a ticket space for you. So even if the conference sells out and your proposal isn't accepted, you'll still have the chance to buy a RubyConf ticket. Instructions on how to do so will be in the email that we send to you.