A developer conference looks, from the outside, like a programme and a room. From the inside it is a sequence of decisions taken in a fixed order, most of them months before anyone arrives, and each one constrained by the ones before it. This section describes that sequence: what gets decided, when, and what each choice rules out.
The order things happen in
The order is almost never varied, because each step is an input to the next.
- Date and venue. These are decided together and first, because the venue’s availability is the hardest constraint in the whole process and everything downstream is measured against the date.
- Track count. A consequence of the room, not a preference. One room means one track; the number of parallel tracks then determines how many talks the programme can hold.
- The call for papers. Written once the shape is known, because it has to state how many slots exist, how long they are and when the decision comes back. Covered in detail under the call for papers.
- Review. A window between the CFP closing and the programme being announced, long enough to read everything twice. See the review process.
- The schedule. Accepted talks arranged into a day, which is a design problem of its own: see programme and tracks.
- Sponsorship runs alongside all of it, on its own calendar, because sponsors budget quarters ahead. The sponsorship section covers it.
Venue first. Everything else bends to it.
Two sizes, and they are different jobs
Almost every practice question has a different answer at a regional conference than at a large one, and most disagreements about how conferences “should” work are really disagreements about which of the two is being discussed.
A regional conference runs one or two tracks for one or two days, in a borrowed or cheap room, with a programme committee of a handful of people reading perhaps thirty to eighty proposals. Tickets cover catering rather than profit. The organisers are volunteers with other jobs, and the event survives by being small enough to run in evenings and weekends. The 2007 and 2008 editions documented in this section are worked examples of exactly this size.
A large conference runs four to eight tracks over several days in a rented convention space, reviews several hundred proposals through a formal committee, and sells sponsorship as a structured product with published tiers. It has paid staff, or a professional organiser, because the work no longer fits around anyone’s day job.
Money separates them as clearly as scale does. A regional event prices tickets to cover catering and hopes sponsorship covers the room; a large one sells sponsorship as a product with published tiers, and the ticket is a real revenue line rather than a contribution to lunch. That single difference explains most of what looks like a cultural gap between the two: an event that does not need a sponsor can refuse one, and an event that has already spent the money cannot.
The interesting cases are the ones in between, an event that has grown past volunteer scale but has not admitted it. That is where most conference failures happen, and it is why the organising page is written around the point at which each decision stops scaling.
What this section covers
- Organising, the decisions in the order above, with the constraint that drives each one.
- Programme and tracks: slot lengths, keynote placement, how breaks are sized, and why a single-track day is a harder design problem than a multi-track one.
- Regional Ruby conferences, an index of the regional events of the 2007–2014 period, with dates and locations as recorded at the time.
- The 2007 edition and the 2008 edition, two consecutive years of one regional conference, in enough detail to read the decisions off the programme.
Which room an event is held in decides most of what follows, and the kinds that work are set out with real examples on venues.
The adjacent sections cover the same event from the other three seats: speaking at one, sponsoring one and attending a first one.
Questions
How far ahead does a conference have to be planned?
Six to nine months is normal for a regional event, and it is driven by the call for papers rather than the venue: speakers need weeks to write a proposal, the committee needs weeks to read them, and accepted speakers need months to book travel and write the talk.
Is one track or two better?
They are different events. One track means everyone shares a reference point and no one weighs a choice between two talks; two tracks fit twice the programme and let a specialist subject be scheduled without spending the whole room’s attention on it. The room usually decides this before anyone has an opinion.
What is the most common mistake?
Scheduling as though the day were a list of talks. Breaks, lunch and the corridor are where most of the value of a conference is produced, and a programme that treats them as gaps to be minimised produces a tired room and no conversations.
Does this section only apply to Ruby conferences?
No. Nothing in the practice pages depends on a language or an ecosystem. Only the regional index and the two edition pages are specific, and they are there as worked examples.