The SCaLE 24x Call for Presentations is open through November 1, 2026.

If you have been thinking about submitting and have not yet, this is for you. SCaLE is one of the friendlier conferences to submit to. We are volunteer-run, we actively want new speakers, and every year a good share of our program comes from people who have never presented at a conference before.

You do not need finished slides to submit. You need a clear idea and a well-written proposal.  The idea is the most important; if our program committee can tell that you have a solid talk idea, we’ll help you with the wording.

Start with your audience, not your topic

You are not giving a talk into a void. You are giving it to a specific group of people sitting in a room in Pasadena.

Before you decide what to say, decide who you are saying it to. Application developers? System administrators? Network engineers? Project maintainers? People who want to make their first open source contribution? Then ask why those people are at SCaLE, and what they need to learn, fix, or build.

Our audience is genuinely mixed - sysadmins, app developers, DevOps practitioners, astronomers, security folks, hobbyists, DBAs, students, and people who just heard about this open source thing and got curious. It is a goal and point of pride to maintain SCaLE as a community as welcoming to students and hobbyists as it is to professionals and industry leaders. Beginner-level talks are welcome and they are wanted. If you were worried your topic is not advanced enough for SCaLE, that worry is probably misplaced.

Picking a topic

Good topics usually come from one of four places:

  • Something you are genuinely an expert in
  • Something you just learned
  • A problem you overcame
  • A controversial topic in your area that you can bring clarity to

The second one is underrated. The best time to write a beginner-level talk is right after you personally graduated to the intermediate level, because that is when you still remember exactly what was hard.

Your topic should mean something to you personally. That is what makes a talk worth sitting through.

The one sentence test

If you cannot express your talk at a high level in one sentence, it is usually because you are not yet sure what the talk is. Three structures cover most talks:

  1. $topic is {cool | easy | hard | fun | terrible}
  2. How to $task by using $technique
  3. {Contribute to | adopt | avoid} $project

Examples: "Rust is the more secure programming language." "How to present better by using thoughtful talk preparation." "Contributing to Python as a non-coder."

Get your sentence, then build outward.

Tell a story

What holds an audience is not code on a slide. It is the story around the code - why it mattered, how you came to it, what went wrong.

Think about what kinds of stories you can tell about your topic.  This could be detailing your process of learning and improving a technique, explaining the steps the audience would take to adopt it, or even a “solution quest” where you relate the things you tried until you found the one that worked.  You could even “show and tell” and then deconstruct how your demo worked for the audience.

Here’s an example from our own program: at SCaLE 17x, Guinevere Saenger gave a talk called "The PR That Wouldn't Merge: How to Take a Year to Become a Kubernetes Contributor." That is a story with a shape, and it is relatable to our audience.

Writing the title and abstract

Your title and abstract are the proposal. They are what the committee reads, and later they are what attendees read when deciding which room to walk into.

Between them, they need to answer three questions:

  • WHAT is the talk about?
  • WHO is it for?
  • OUTCOME - what will the audience walk away with?

 

A few practical rules:

  • Make it concrete, not generic or buzzwordy.
  • Say what the talk is about in the first sentence or two.
  • Spell out acronyms and explain jargon.
  • Keep it a reasonable length. Three short paragraphs is plenty.
  • Make sure the title and the abstract promise the same thing.
  • State the outcome explicitly so people can self-select.

One thing that surprises people: whatever you type into the CFP tool is exactly what gets published. There is no data entry step afterward. Your abstract, your bio, and your headshot go straight to the website and the printed program. That said, if your talk is accepted, you will have time to edit it before publishing.

We ask for two abstracts and they have different jobs. The short abstract goes in the printed schedule, so keep it tight. The long abstract and your bio go on the website. Bios should run under 1,000 characters and read better in the third person. In addition to the website, the graphics team will use your photo to create social media graphics to help us (and you) promote your session.

Use the Message to Reviewers

The title/abstract/bio are what attendees eventually read but the Message to Reviewers field is only for the committee. This is the place to speak directly to the committee to clarify, ask questions, request followup, and flag anything you want our attention on, including scheduling constraints or accommodation needs. Reviewers are specifically told to read that field, because you put it there for them.

Submit early

We do get a rush of submissions right before the deadline. It is in your best interest to beat the rush. Before the deadline, committee members have time to look at proposals, notice promising ones, and reach out to help tighten them. When the CFP closes, we are heads-down on several hundred submissions and that window is gone.

You can revise your submission any time before the deadline. So do not sit on an unpolished abstract waiting until it is perfect. Put it in the system early and keep working on it. You can include a note in the Message to Reviewers if you have specific changes coming.

If you want feedback on an abstract, the right move is to submit it and then ask - not to polish it privately and submit at the last minute. 

Do not agonize over the track

Pick the track that seems closest and move on. Most talks could plausibly live in more than one track, and we do a fair amount of swapping during selection. If your proposal fits better elsewhere, we will move it and email you about it.

What we do ask is that you not submit the same proposal to multiple tracks. Duplicates make more work for reviewers and confuse the process.

Proposals That Will Not Be Accepted

We are a conference about Open Source in all its many varied incarnations. Your talk must tie into open source. If your talk is about proprietary software, it will not be selected. It’s totally fine if the project you’re talking about also has an enterprise/private version - but focus on the open source parts.

SCaLE talks are not product pitches. If your proposal describes a problem for ten minutes and your product's solution for forty, it will not be selected.

Working for a vendor is completely fine; many of our speakers do. Keep the talk focused on the open source project rather than the commercial product, and ask yourself whether an attendee could go download and run what you are describing without buying anything.

Further, do not make the actual topic of your talk a mystery.  When the program committee sees “Come to my talk to learn which tools I used” their assumption will be that it’s a product pitch.

If you do want a product-focused session, that is a legitimate thing to want, and we have sponsored sessions and sponsored track days for exactly that. Email sponsorship@socallinuxexpo.org.

Submit more than one

If you really want to speak at SCaLE, submit more than one proposal. That can mean genuinely different topics, or different treatments of the same material: a one-hour session and a workshop version, or a beginner introduction and a deeper technical dive. Variations help us, because one of our main jobs is building a balanced program across audiences and experience levels.

Submitting Workshops

If you are considering a workshop: they run longer, go in the Workshops track, and need any prerequisites listed in the proposal. Do not make a workshop your first-ever talk, since it takes several times the runtime and many times the preparation. And plan on more than one presenter, including someone driving the material and at least one more helping attendees who get stuck.

You will get a response

Add cfp@socallinuxexpo.org to your contacts now. We send acceptance and rejection notices from this address. Everyone who submits gets an answer, but only if it reaches you. People have missed an acceptance due to the email landing in their spam folder. Corporate mail filters are the usual culprit. 

Submit

The SCaLE 24x CFP closes November 1, 2026. The conference runs April 1-4, 2027 at the Pasadena Convention Center.

We would rather see a rough proposal in September than a perfect one on October 31. Start now.

 

 

Much of the advice here comes from a new speaker session run by SCaLE Program Committee members Josh Berkus and Lan Dang. https://www.youtube.com/watch?v=wAvD59BfJ2U