How developer conferences get made: the programme and the speakers

Almost everything written about a developer conference is written by the conference itself: a call for papers, a schedule, a sponsorship page. Very little of it explains the mechanics what a review committee weighs, why abstracts are capped at a few hundred words, what a sponsor tier is priced against, or how a beginner track is put together. The knowledge exists, but it sits in the heads of the people who have organised an event, and it is passed on by conversation.

This site writes it down. Each section covers one side of the same object: proposing a talk, funding the event, arriving at it for the first time, and the programme that holds it together. Where the answer depends on tooling rather than on practice (a Ruby version's end-of-life date, which linter a project should run) that belongs in the Ruby and Rails section instead.

Every page here answers one question and links to the next one.

About the name

The domain is named after Ruby Hoedown, a free regional Ruby conference that ran in the American South between 2007 and 2012. It was one of a set of small, cheap, single-track events that made up the regional conference circuit of that decade, and the format is worth documenting precisely because it worked: a low ticket price, a short programme, and a call for papers open to people who had never spoken before. That circuit is covered, in the past tense and with sources, in the regional conference index.

The word itself came to the conference from somewhere older, and “hoedown” has its own page for readers who arrived looking for that rather than for a programme committee.

How the pages are built

Every section has one page that covers the whole subject and a set of pages that each go one level deeper. The section card in the margin lists all of them, so any page is one click from every other page in its section. Three of them carry a tool rather than an essay: a proposal builder that assembles a submission field by field, an index of regional conferences that can be filtered and sorted, and a release timeline with the support dates on it. All three run in the browser and store nothing.

Speaking

The pillar explains the call for papers itself: the window, the fields, the review model, and what a committee is weighing when it reads two hundred submissions for twenty slots. Around it sit the parts of a submission that are written separately: the abstract, which is the only part that decides whether a session exists; the title, which is what the shortlist is sorted on; and the bio, which answers relevance rather than seniority. Two pages cover the outcomes instead of the submission: how a shortlist becomes a schedule, and what a decline does and does not mean.

Sponsorship and scholarship funds

Sponsorship is the least documented side of a conference and the one with the most money in it. The section works through the tier structure and what each level is priced against, what a prospectus has to state before it can be taken seriously, and the honest version of what a sponsor receives, which is rarely the logo placement the tier is named after. Scholarship funds get their own page because they are the one line item that changes who is in the room.

Newcomers and Ruby

The newcomer section is built around the observation that a first conference is mostly navigation: which talks to skip, where the hallway track happens, whether a beginner track is worth the slot, and how mentorship is arranged when it works at all. The Ruby section answers the questions that turn out to be about tooling rather than practice: which version is still supported, what static analysis is worth running, and how testing is usually structured in a Ruby codebase.