What Go conference reviewers look for in a talk proposal

In 2024, I reviewed 233 GopherCon talk proposals as part of the review committee. As a reviewer, I had to judge proposals solely on what’s written, not assume anything, and identify what value the talk will deliver to the audience. That last question was missing from most submissions. Even proposals with detailed outlines and obvious effort forgot to provide the critical piece: why should a Go developer care about this talk?

My ratings were roughly bell-shaped, clustering around 2 to 2.5 stars, with very few proposals earning 4 or 5. According to the scoring guidelines, 3 means a good talk with nothing specifically wrong. Most proposals scored below that threshold not because they lacked technical depth, but because they never answered: what will attendees walk away with? If you’re writing a conference submission, your first paragraph should answer three things:

1. What is this talk about?
2. Why does Go matter?
3. What will attendees take away?

Strong proposals answer these immediately. Weak proposals make reviewers hunt through outlines looking for information that should have been obvious upfront. When the pitch doesn’t land in the first paragraph, no amount of detail in your outline can fix this.

Reviewers are reading many proposals back to back, trying to understand the value of each one as quickly and fairly as possible. They are operating under time and cognitive constraints. When your opening isn’t clear, they start guessing instead of evaluating, which hurts even good proposals.

After reviewing dozens of submissions, a few proposal archetypes showed up again and again:

• The README Talk: The proposal reads like: I’ll spend 25 minutes walking through this framework’s features. If your outline looks like project documentation, it’s not so much a talk as it is a demo. What distinguishes a talk from a demo is narrative, perspective, and hard-won lessons.

• The Incidental Go Talk: If you could replace “Go” with another language without changing the meaning, the proposal is likely not strong enough. Go should shape the talk’s content. A strong proposal explains why the approach, examples, or lessons land differently because of Go. What trade-offs came from Go? What became simpler or harder because of Go’s tooling, standard library or ecosystem?

• The Missing Go Talk: Many proposals don’t even mention “Go” anywhere, going as far to bring up the question: what does this have to do with Go? Reviewers are left guessing how Go connects to the topic, which means they can’t realistically evaluate the proposal as written.

In my experience, most conference attendees are new to Go and attending their first Go conference. They’re not looking for framework tours or tool comparisons. They’re looking for practical advice: mistakes to avoid, patterns that work, anything you discovered the hard way. That’s what “audience value” means.

The good news: this is fixable. You don’t need massive scale, impressive numbers, or a revolutionary idea. Most attendees can’t relate to “we serve 10 billion requests per day”. What resonates is a story about a real problem and what you learned along the way. Start with why someone should care, then build the proposal from there.

If you’re working on a conference proposal and want a second set of eyes on whether these three questions are clear, I’m happy to review it.