I’ve submitted a lot of talk proposals to a lot of Postgres conferences over the years. Some got accepted, many more were not. And I’ve been on the other side of this process too, as a member of the CfP committee responsible for selecting talks. So let me give you a couple suggestions on how to write a good talk proposal.

Firstly, this is not a post “Do these 3 simple things and you’ll get your talk accepted.” No matter what you do, there’s no way to guarantee your proposal will be selected. If there are 50 slots and 400 proposals, clearly some talks won’t make it. And it’s not like the other speakers are not trying to write good proposals too.

A lot of the suggestions are very subjective or even biased. But I hope it can still be useful when thinking about your proposal.

What should the talk be about?

I have no idea, really. That’s entirely up to you. It needs to be about something Postgres-related, but the rest is up to you. It should be interesting to other attendees, so maybe consider what kind of event the CfP is for. Is it more of a user conference (like PGConf NYC), or will there be a lot of developers (like at pgconf.dev), or a mix of the two (like pgconf.eu)?

I probably would not submit a talk about low-level internals to a user conference, or something clearly user-oriented to pgconf.dev. But those are not hard rules, of course. A good way to judge if your talk would be a good match is to look at schedules from previous years, and see if your talk would “fit” into those. Are there talks for the same audience?

I strongly advise against proposals on the current hot topic. Don’t submit a proposal about X just because everyone else talks about X. Sure, if you actually know a lot about X, no problem with that. But if you came up with the idea to submit a talk about something just because it’s the hot topic, so did plenty of other people. There will be a zillion similar proposals, and the program committee does not want the whole schedule to be on the same thing/. So most of those proposals will get rejected. Who would have guessed, right?

An obvious example of this is “AI” at the moment.

The best thing you can do is to propose a talk about something you work with. It might be something quite unique (e.g. an uncommon use case and how you managed to handle that with Postgres). Or something a lot other users have to deal with (say, how to investigate slow queries).

It’s entirely up to you. My feeling is it’s probably better to pick a topic that is a bit unique, because the program committee wants to have a variety of talks, to give attendees some choice.

The topic is not advanced / new enough!

I’ve heard a couple people explain that they didn’t submit a proposal because their topic is too simple. Or that it would not be “advanced” enough. Or that there already was a similar talk two years ago.

That reasoning does not make much sense - we do have new attendees every year, right? And they do need “beginner” talks explaining the basic concepts from scratch. And because they are new, they also have not attended the old talk.

And no one saw all the talks from previous years of the conference. And the experience of attendees does not grow year over year. There will always be new attendees - either new to Postgres in general, or to the conference.

We do need beginner talks! We do need talks about existing use cases!

Make it short!

So, you finally decided what topic you want to talk about - congrats! And you have already prepared an outline of the talk, so you mostly know what you are going to talk about. Which means it’s time to write an abstract describing the talk, which is what the attendees will see. But it’s also what the program committee will evaluate and grade.

What is a good abstract? I suggest you approach abstracts a bit like an elevator pitch - you step into an elevator with a random attendee, and you have 30 seconds to convince them to attend your talk.

I strongly advise to keep it short. The fact that the form allows 1MB text fields does not mean you have to use all of that space. I try to stick to one or two paragraphs, no more than 500 characters in total.

Do you expect the program committee to read a wall of text just to understand what your talk is about? I have my doubts. As mentioned by Karen Jex in her post about talk selection at pgconf.eu 2024, this year there were almost 380 talk proposals. If evaluating a single proposal requires 10 minutes to read and evaluate, evaluating all 380 would be about 60 hours. A lot of time for a volunteer unpaid work.

The other thing is what to put in the abstract. Focus on two things: (a) what the talk is about and (b) what will the attendees learn from it. Are you going to talk about slow queries and the attendees will learn about new ways to investigate and fix those? Cool, put that in the abstract. Do you plan to share your experience with migrating a legacy system from database X to Postgres, and show which of the available tools worked well and less well? Cool, put that in the abstract!

If you’re tempted to write a funny abstract, maybe reconsider. 99% of the time it’s not a good idea, because the “funny” part requires quite a bit of context, which a random person may not have. In which case it just makes the abstract unfunny and hard to understand.

Write the proposal yourself

I wouldn’t have believed I’d have to write this, but you should write the abstract yourself. I mean you personally - not the gnomes hidden in some LLM model in the cloud. Sit down, think about the talk you plan to do, and hit the keyboard until you have an abstract.

I did see a couple proposals obviously generated by a LLM, and most were pretty ridiculously bad. You start reading the first paragraph, and after a couple sentences you realize “Huh?! This makes no sense. I must have missed something …” so you go back, start reading again, … And then you realize it actually doesn’t make sense, it’s completely devoid of it. And not only that, it’s also many pages long.

I understand people use LLM to summarize long text (papers, for example) and that it’s pretty good at it. But I’m not sure that works well enough for slides, or that the result is usable as an abstract. Slides are often quite incomplete - basic bullet points for the talk, etc. But even if that worked and the summary made sense, that still does not qualify as a good abstract for the CfP. It might give you the outline of the talk, not the two bits I think a good abstract should have.

This does not say to not use tools that help with readability, grammar etc. But I’d much rather read an abstract with grammar mistakes over a meaningless LLM garbage with perfect grammar.

No sales pitches

Our community includes many companies, some of which develop both open source and proprietary products. Sometimes even in the same area. For example, people may be working on HA/replication, and the employer has managed services leveraging that. Or they may be working on logical replication, and the company is building an active-active solution.

There’s nothing wrong with that, and I’d even say it’s a strength of Postgres. But it also means that when a person submits a proposal about a feature, there may be a concern the talk may pivot to the proprietary thing.

And these concerns are not unfounded - this does happen once in a while, and it’s quite annoying (both for the attendees and program committee). It won’t work for long, because guess what - the attendees/organizers talk to each other (you know, there’s a global communication network). And once you’re known to do this “bait-and-switch” thing …

If you don’t plan to talk about your proprietary thing (at least not extensively) but realize people might be concerned about it, it’s a good idea to mention that in the submission. Not in the abstract, but there’s usually another field for additional comments about the talk. Something like this:

I’m going to talk about feature X. We have a product Y related to that, and I’ll mention it, but I’m not going to talk about Y much.

If you plan to talk about the proprietary product a lot (or when it’s the point of your talk), disclose that too. My experience however is that program committees don’t like such talks. After all, it’s a community conference, and if the product is not freely available … Not a good match, IMHO.

But there may be a solution - some conferences (including for example pgconf.eu) have a “sponsor track” for exactly such talks. I’ve been a bit skeptical about this initially, but I’ve changed my mind. The talks are generally really good, and if it’s clearly marked in the schedule/abstract, the attendees have all the information to decide.

Submit more proposals (but not too many)

The last thing to discuss is the number of proposals. Most conferences don’t limit the number of proposals, some do. For example pgconf.eu set the limit to 4 proposals per speaker this year, if I’m not mistaken. So, how many should you submit?

Similar to the length of the abstract, my recommendation is to not overdo it. I know speakers who have a long list of talks they can give, and they simply submit all of them to the new conference. It can easily be 5 or 10 talks. Those talks may be good (or even great), and the motivation is also good (“Here’s 10 nice talks I can do, pick what best fits the schedule!”). But I think this can work against the speaker and backfire.

Why? Talks should be evaluated independently, ignoring other proposals from the same speaker etc. But nothing is perfect, and when you see 10 talks from the same person, the natural thing is to ask which of the 10 talks you like the most. And then maybe some of the talks are graded a bit lower compared to “independent grade.” If multiple people do this, it can skew the resulting grade a bit, to lower values.

It also increases the load and pressure put on the program committee. Dealing with 300+ proposals is already hard, let’s not make it worse.

1-3 proposals seems like a reasonable number to me. I usually submit 2 talks, and I try to make them different to give the program committee a bit of variety, in case someone submits a very similar talk. I also try to combine a talk that I’ve done before (even if updates/tweaks are needed) and a new talk that I’ll need to do from scratch.

Conclusion

One last thing - it may be a good idea to ask someone else (a colleague or just someone else in the community you trust) to look at the proposal and give you feedback / suggestions.

And that’s it.