How to write a good abstract

Five points to follow in your proposals



Writing proposals for conferences and events is not a simple task. Usually we believe that a clickbaity title can do us a favor, or sometimes we believe because we are very related to a topic we can give an excellent talk.

The issue is always that reviewers might not know you, in some cases the reviews are anonymous, so you need to do a very good job of writing an abstract that can "show the reviewers" you are capable of discussing that topic, and that the talk is worth accepting.

Some people like to think that an abstract needs to be an elevator pitch of your talk, so you need to provide a certain structure in order to be a good proposal, which I completely agree with.

Why I'm writing this

During the last years, I have been a reviewer and also in charge of the Program team of many conferences, and I cannot emphasize how much you will gain by having a well-structured abstract. Still by this day, I see proposals that are 1 or 2 phrases on a certain topic without context, nor problem definition, so please take the time to write a good abstract.

Please note: Having a well-structured abstract doesn't guarantee you to get a talk accepted, I get proposals rejected all the time, but I promise you it will help you greatly.

The 5 key points for a good abstract

For that, I'd like to share five key aspects that an abstract needs to have in order to provide all the required information to reviewers, and make you feel proud of your submission.

  1. "Start your abstract by giving a bit of context, so people can understand the main motivation." It's a recurrent problem of proposals when the submitter assumes that reviewers will know about everything they are referring in their proposal.

  2. "Define the problem/project, so readers will know the main objective you are trying to reach." You had a special motivation before starting to write the your talk, share it with the audience!

  3. "Describe the importance of a solution for such problem/project." In bold terms, why people should care about your talk? Even if it's a specific field, you might encounter that error in other areas.

  4. "Share a bit of the precise topics/examples/areas that will be discussed on your talk, and maybe engage with the audience by telling them «what they will learn» if they attend." A typical paragraph that start with "On this talk, you will..." might work.

  5. "Let people know if they need to have some previous knowledge for attending your talk." This help readers but also reviewers, mainly to match the talk-level you provided, with the audience that's expected.

And that's all!

Extra point

In some conferences (PyConUS, EuroPython, etc) you are also required to write an outline for your talk, and in most cases detail on the time you will expect on each item is required as well.

For this, please avoid a simple outline like "Introduction, Main talk, Conclusion", and instead detail the topics you will be talking (with some description).

It's fine to give introductions to certain topics, but you might want to add if the type of introduction, or the details you want to highlight. The same with the content of the talk, maybe you want to discuss implementation details of your project, and then provide a few live-examples, add that information as well, and estimate a time per each item, so reviewers can see how the total time of your talk will be distributed.

Is that all?

Many conferences offer speaker mentorship programs, or even some feedback rounds on the proposals, please take them! Even if you believe you have 10+ years experience in the field, your proposals might have holes in it, or you might start from the base everyone in the review committee knows the background of your topic.

Feedback is very useful, because it will teach you "what is conference X looking for", and you might end up having different abstracts tones depending on the conference you are applying to.

And like many other things, if your proposal get rejected, keep trying! some times rejections are not a "your proposal is bad" but more like "we decided to use another proposal because of X".