Update structure

Author: hschne

_includes/conferences/after-the-conference.md

@@ -0,0 +1,35 @@
+## After The Conference
+
+The conference ends. The venue goes quiet. Your volunteers go home. And then, usually the next day or two, the post-event slump hits.
+
+This is normal. You spent months of accumulated energy and it just discharged all at once. Give yourself a few days before trying to do anything productive with the aftermath. The feedback forms will still be there.
+
+### Settle the finances
+
+Within the first week or two after the event, close out the books. Pay any remaining vendor invoices. Reconcile what came in with what went out. If you are running as an LLC, keep records clean for tax purposes.
+
+The financial reality of your first event is useful data for your second. What did you over-budget? What surprised you? Where did you get it right?
+
+### Gather feedback
+
+Send a feedback survey within a week while memories are fresh. Ask what worked, what didn't, and what people wanted more of. Ask about specific decisions: the venue, the talk format, the lunch arrangement, the pacing.
+
+A handful of pieces of feedback will be people telling you what they expected and didn't get. Separate those from the structural feedback. Someone upset that you didn't have catered lunch is not necessarily telling you to add catered lunch — they may be telling you that the lunch situation was confusing, and clear communication about open lunch would have set better expectations.
+
+### Video: a different view
+
+If you recorded the talks, you may feel pressure to publish them quickly. Resist the urgency. Most people who will watch a conference talk watch it months after the event, if at all. Taking a few weeks to produce clean video is better than rushing out rough footage.
+
+Andy Croll takes a deliberately long time with Brighton Ruby's video, usually publishing around Christmas — which also gives him a natural moment to email the community and promote the next year's event. He also hosts the videos on his own site rather than YouTube, keeping them as a reason to come back to Brighton Ruby specifically rather than just adding to the generic conference-video pile on the internet.
+
+This is a contrarian position, but it reflects a real choice: video is for the people who didn't come. The people who came were there. Treat the video as a marketing asset for year two, not an obligation to fulfill immediately for year one attendees.
+
+### Should you do it again?
+
+This question usually answers itself. If the event went reasonably well — people came, something connected, the finances didn't collapse — you will probably want to do it again. If it was a disaster, you may still want to do it again, better.
+
+The second year is meaningfully different from the first. You have a track record. Sponsors have seen it exist. Attendees who came once will decide whether to come back. You have real data on ticket sales timing (most people buy late, but not as late as you fear; plan accordingly). You know what you over-prepared for and what surprised you.
+
+The second year is a little easier — not easy, but easier, because the unknowns have become knowns. That incremental reduction in uncertainty is the reward for doing the first one.
+
+---

_includes/conferences/before-you-commit.md

@@ -0,0 +1,47 @@
+## Before You Commit
+
+Before announcing your conference get the fundamentals locked down. Not just thought about — actually decided and signed. Date, venue, rough budget. Everything downstream depends on those three things, and announcing before you have them in place creates pressure without any of the infrastructure to support it.
+
+### Find your date
+
+Your date is more constrained than you think. You need to avoid major local events. Any of those can wipe out hotel availability and drive prices up. Look at which other Ruby or Rails conferences are happening nearby on the calendar. Take holidays - both local and international - into account.
+
+If you're shooting for spring or fall, give yourself plenty of runway on either side of the major conference anchors. Start with a date range of two or three candidate weekends and proceed with those.
+
+### Find a venue
+
+Once you have possible dates, find the venue. This is not step three or four — it is step two. Everything else, including your budget and your ticket price, depends on what the venue costs and what it includes.
+
+The venues that work best for 100-200 person single-track conferences are usually not hotels. They are theaters, old music venues, cultural spaces — places that sit empty during the day and have an actual stage, fixed seating or flexible floor space, decent AV, and nice staff.
+
+Hotels are the obvious choice and almost always the wrong one for a first conference at this scale. Most hotel venues require a room block commitment alongside their event space — meaning if you expect 100 attendees and they make you hold 80 rooms, you are on the hook for any rooms that don't fill. Add a food-and-beverage minimum on top of that and you can find yourself owing tens of thousands of dollars regardless of how many people show up.
+
+Hotels are also slow to respond, difficult to negotiate with, and often have catering requirements that eliminate the most effective cost-cutting option available to you: skipping lunch. If you must evaluate them, get crystal clear on the room block terms and the F&B minimum before any deposit changes hands.
+
+When you visit venues, ask about what's included in the day rate, AV setup and internet access, setup and teardown time before and after the event, catering exclusivity requirements, and what their staff handles versus what falls to you.
+
+{% capture venue %}
+Boulder Theater was Rocky Mountain Ruby's original home. eTown Hall - an old church converted into a radio studio and performance space - is where it lives now. Blue Ridge Ruby's first venue was a theater in a Masonic temple. Balkan Ruby latest venue a geology museum. These are not conference centers - they are interesting spaces that happen to work for a conference, and they tend to cost dramatically less.
+
+{% endcapture %}
+{% include tip.html description=venue %}
+
+{% include testimonial.html
+  quote="Venue is a really important piece of the process, and I recommend you do that first once you get clarity about what you want. Because if you don't know what you want, then as you look at venues, it may crystallize."
+  name="Marty Haught"
+  conference="Rocky Mountain Ruby"
+  avatar="/assets/images/avatars/marty.jpg"
+  initials="MH"
+%}
+
+### Legal structure and insurance
+
+You do not legally need a company to run a conference. The venue will happily sign a contract with you as an individual and take your personal check. But if you plan to run the event more than once, or if you are running it with other people, setting up a company is worth the small overhead. It keeps the finances separate, creates a clean entity for sponsors to pay, and means the conference has a legal identity that can survive you stepping back.
+
+### Give yourself a year
+
+A first conference needs roughly twelve months from decision to event. That may feel like a long time, but it disappears quickly. Venues book up — especially good ones. Sponsors have annual budgets that are often allocated months in advance. Attendees plan travel. A CFP needs time to run, evaluate, and notify speakers. Swag needs to be ordered earlier than you think.
+
+Six months is doable but stressful. Less than six months is possible but not recommended for a first-time organizer.
+
+---

_includes/conferences/finding-supporting-speakers.md

@@ -0,0 +1,87 @@
+## Finding & Supporting Speakers
+
+Getting speakers for a regional Ruby conference is usually not as hard as first-time organizers fear. The Ruby community has a strong culture of speaking at community events. When you run your first CFP, you will get more proposals than you have room for. That kind of response is not universal, but it is not unusual either.
+
+### CFP or curated?
+
+A CFP opens the door to people you don't know, which is valuable — especially for a first-time organizer without a wide network. You will get proposals from people you wouldn't have thought to contact, and some of those will be your best talks. A CFP also signals a fair, community-oriented process, which matters to some speakers and attendees.
+
+Curating your lineup means reaching out directly to people you want to speak. Jason Swett did this at every Sin City Ruby, building his program around people he thought would draw an audience and give good talks. If you want invited keynotes on top of a CFP, approach those conversations early — before you announce the CFP — so you can open with at least one confirmed name that gives people a reason to submit.
+
+### How to run a CFP
+
+A CFP is more than a form. It is outreach, deadlines, review, selection, and a lot of email. If you treat it as "open form, wait, pick talks," you will make the hard decisions too late.
+
+Start by deciding what kind of program you want before proposals arrive. Do you want mostly technical talks? A couple of non-technical talks? Local speakers? First-time speakers? Talks from people who do not already speak at every Ruby event? Write that down. It does not have to become a public manifesto, but the organizers should know what they are selecting for.
+
+The CFP page should say what you are looking for, how long talks are, who the audience is, whether talks need to be original, what support you can offer, when the CFP closes, and when speakers will hear back. If first-time speakers are welcome, say that plainly. If you can help someone shape a proposal, say that too.
+
+### Build a CFP committee
+
+Do not review everything alone if you can avoid it. Three to five reviewers is enough for a small conference. You want people who understand Ruby, understand the audience, and will actually read the proposals before the deadline. That last part is not a joke.
+
+Give reviewers a simple rubric: clarity, relevance, audience fit, originality, and how well the talk fits the program you are trying to build. Blind review can help, but it is not magic. Some proposals are identifiable from the topic alone. The important thing is that reviewers share enough context to make consistent decisions.
+
+When review is done, assemble the program as a whole. Do not blindly take the highest scores. Two great talks on the same narrow subject may be worse than one of those talks plus something that changes the shape of the day. A conference schedule is a composition, unfortunately.
+
+{% include testimonial.html
+  quote="We always did the CFP together. We also had some help doing the CFPs... we didn't necessarily want it to just be me and Ernie doing it. We wanted more input."
+  name="Jason Charnes"
+  conference="Southeast Ruby"
+  avatar="/assets/images/avatars/jasonc.png"
+  initials="JC"
+%}
+
+### Give the CFP enough time
+
+For a first conference, open the CFP four to six months before the event if you can. Keep it open for a few weeks, remind people while it is open, then close it when you said you would. Give reviewers a week or two. Notify accepted speakers before you announce anything publicly, and tell declined speakers promptly. Leaving people in limbo is a bad look and makes it harder for them to plan their own year.
+
+CFP marketing is separate from attendee marketing. Post it in speaker communities. Ask meetup organizers to share it. Personally encourage people whose perspective you want in the room. If you want underrepresented voices, do more than put "everyone is welcome" on the page and hope the right people see it.
+
+{% include testimonial.html
+  quote="When opening the CFP, it was always important for us to reach different groups of people... support or motivate people from underrepresented groups, or voices which are not always heard that much, that they also submit talks."
+  name="Hana Harencarova"
+  conference="Helvetic Ruby"
+  avatar="/assets/images/avatars/hana.jpeg"
+  initials="HH"
+%}
+
+### Accepted, declined, and waitlisted speakers
+
+Accepted speakers should get one clear email with the talk title, talk length, event date, speaker benefits, travel or hotel details, slide or rehearsal deadlines, and what you need from them next. Declined speakers deserve a clear answer too. You may not be able to give detailed feedback to everyone, but you can at least not leave them wondering.
+
+Keep a short waitlist. Speakers cancel. Travel falls through. Life happens. A waitlist only helps if waitlisted speakers know where they stand and when you will make the final call.
+
+### What speakers need
+
+Speakers are putting in work to speak at your event. A 30-minute conference talk can represent between 30-80 hours of preparation. The minimum you can offer is a free ticket, a clear answer to every logistical question before they have to ask it, and a response when they email you.
+
+You may also consider a honorarium. Even if it does not cover much of a flight, it is a gesture of respect. Many speakers don't take it, particularly if their company is paying for travel — in that case, offer to list their company as a sponsor in lieu of the cash.
+
+If you can cover hotel, do it, especially for speakers coming from far away. If you can't cover travel, be honest about that upfront so people can make an informed decision.
+
+{% include testimonial.html
+  quote="These people are putting themselves out there. Without the speakers, there is no show."
+  name="Andy Croll"
+  conference="Brighton Ruby"
+  avatar="/assets/images/avatars/andy.jpg"
+  initials="AC"
+%}
+
+A speaker dinner the night before the conference is worth more than it costs. It gives speakers time to meet each other before they're on stage, gives you time with people you've been coordinating with only by email, and sets a tone for the whole event.
+
+### Supporting first-time speakers
+
+If someone has never given a conference talk before and is in your lineup, they need more from you than an experienced speaker does. Ask to see a draft of their slides a few weeks out. Ask what they're nervous about. Offer a practice run if that's useful to them.
+
+Not every organizer has the time or the expertise to build full speaker mentorship into the conference. But even a quick conversation a week before the event, asking how the talk is coming and whether they have everything they need, goes a long way.
+
+{% include testimonial.html
+  quote="The investment I put through with the speakers before the talks — helping them finesse their presentations — I think makes a real difference."
+  name="Andy Croll"
+  conference="Brighton Ruby"
+  avatar="/assets/images/avatars/andy.jpg"
+  initials="AC"
+%}
+
+---

_includes/conferences/format-identity.md

@@ -0,0 +1,49 @@
+## Format & Identity
+
+Before you start selling tickets, you need to know what kind of conference you are running. Not just the logistics — the shape of the thing. Single track or multi? One day or two? What kind of event is this, and why would someone spend a day or more of their time coming to it?
+
+### Single track
+
+For a regional conference in the 100-200 person range, single track is almost always the right answer. Multi-track events requires more space, more coordination, more speakers, and forces attendees to make choices that fragment the shared experience. The whole point of a small conference is that everyone is in the same room together. When half the room goes left and half goes right for every session, you lose the shared frame of reference that makes the hallway conversations work.
+
+Single track also simplifies your job considerably. One room, one schedule, one speaker in the slot at a time.
+
+{% include testimonial.html
+  quote="The advantage of a small conference like Rocky Mountain Ruby is we can do both — we have lots of time, and everyone sees the same talks. I think there's something to people in a single-track conference all seeing the same talks. They all have the same frame of reference when they're talking in between."
+  name="Spike Ilacqua"
+  conference="Rocky Mountain Ruby"
+  avatar="/assets/images/avatars/spike.jpg"
+  initials="SI"
+%}
+
+### How many days
+
+For your first conference, aim for either one or two days. One day is lower financial risk, requires less from attendees in terms of travel commitment, and is easier to program. Two days gives more room for the hallway track to develop, allows for a mix of formats (workshops on day one, talks on day two, for example), and makes the trip feel more worthwhile to people who have traveled far.
+
+For a first conference, one day is the safer choice. You can always add a second day in year two.
+
+{% include testimonial.html
+  quote="Brighton Ruby has been a one-day single-track conference for over a decade and now draws 450 people. I tried tried expanding it and stepped back every time. I can't do two days. I don't have the energy to do a two-day version. And the one-day version works."
+  name="Andy Croll"
+  conference="Brighton Ruby"
+  avatar="/assets/images/avatars/andy.jpg"
+  initials="AC"
+%}
+
+### Know what your event is
+
+This is more important than it sounds. A conference with a clear identity — a specific city, a specific vibe, a specific sense of what kind of community it is for — is easier to sell and easier to run than one trying to be everything.
+
+Blue Ridge Ruby is explicitly tied to Asheville - the food scene, the mountain setting, the post-conference river tubing. Friendly.rb in Bucharest leans into its European location with city walking tours and a mountain day trip on the third day. Rocky Mountain Ruby is a tight community conference in Boulder for people who want good talks and long breaks to talk to each other. RubyConf Austria did a blend of Ruby and classical music - featuring piano performance and a choir opening the conference.
+
+This is not about aesthetics, these concerns are part of what you are selling. Don't accidentally build a generic conference when you could build one that feels like something special.
+
+{% include testimonial.html
+  quote="Be intentional about what you're trying to do, and tell people about it."
+  name="Adrian Marin"
+  conference="Friendly.rb"
+  avatar="/assets/images/avatars/adrian.jpg"
+  initials="AM"
+%}
+
+---