RustFest speakers guide

Hi fellow human! You are receiving this document because you are speaking at RustFest. We are happy to have you on stage!

Before we start: this is a guide, and while I will talk about recommended speech patterns, this is not a strict ruleset to follow. You know yourself best. As long as you are not violating the Code of Conduct, the worst that can happen to you is feedback.

This document is here to help you in your preparation of your talk. Please note that it is for everyone. Because we have experienced and beginner speakers, the document is divided in sections.

  • Must-knows: The must read. It holds all the technical information and some particularities about our conference.
  • Audience: A description of the audience at the conference.
  • Ableism: RustFest does have a focus on being an accessible conference for people with disabilities and ableism is an often-forgotten topic when speaking to them. You should probably read this.
  • Accessibility: Your talk and your slides should be accessible to as many people as possible. We provide some tips and resources on things to look out for.
  • Beginners: Many words for beginners. If you are experienced, you may or may not want to read this, too, but you are not the focus group of this.
  • Schedule: Have a look at the provisional schedule. Let us know if there are any issues.
  • Travel Info: If you stay at the speakers hotel, please read through this.

If you have never given a talk at a conference before, please follow the instructions on what happens on the day exactly, to decrease stress and increase happiness.

You will additionally receive a running list for the day shortly before the conference.

Must-knows

Send your travel info

If you need help upon arriving in the city, e.g. getting picked up from the airport or train station, please send us your travel details as soon as possible.

Upload your slides

<RustFest had a person with vision impairments attending. Therefore we asked our speakers to provide their slides (or some drafts at least) 2-3 weeks before the conference, as it takes some time and work to make them accessible to that person.>

Also, please prefer uploading a draft soon (possibly now), even if it doesn't have all content or just a beginning. It helps catching problems when converting your slides early on! Please try to have something in that folder by Sunday, <1 week before the conference>, latest.

Because of this, please read the section on accessible talks on the conference, and try to act by it.

Please note that our Code of Conduct applies to slide material and talk content.

Technology

<General information about the screen and mic setup, planned licenses for publication, and talk transcription (if applicable).>

Things to do before the talk

Please try to be on time so that we can arrange a technology check.

Please meet our master of ceremonies before the talk section to make sure they have something nice to say about you. Maybe come up with something yourself, something about an area of interest or a little personal story you are comfortable with someone telling on stage.

If all this is new to you, refer to the relevant part in the beginners section.

Giving accessible talks

Everyone should be able to follow your talks, so here's a few guidelines. It's not even much you have to do and it improves your talk for everyone.

First of all, you probably have an accent, even if you don't realise. For that reason, try to speak slow, clearly and loud. Make an effort not to be too fast.

Make sure you don't cover your mouth on stage. People with hearing impairments will thank you.

Second, explain anything that is on your slides, even in their spatial relationship. ("To the left, you see A, down at the bottom, there's B and their relationship is a road over point C")

This is especially important for people with any kind of visual impairments.

Please don't make trivial jokes like "let's say something really hard just to have her cope with that" with the transcription interpreter. This has sadly been an issue before. Interaction with her is fine, though, keep it sincere!

Audience

Beginners note: knowing your audience is important! A talk in front of a specialist audience is entirely different from a talk in front of a generalist audience. Different audiences need different content. A joke that is fun in one room is not fun in another and the other way around.

RustFest is a community conference about the Rust programming language, which is relatively young, but has gathered some attention. It has especially found a way to engage new people in systems programming. Assume the audience to be a mix of experienced systems programmers and fresh people and try to cater to both. We also hope for a rather diverse audience and the tech communities we interact with tend to take diversity seriously (more on that later).

Be aware that many attendees will have an acceptable level of English skills, but will not have English as a first language. Thus you may consider avoiding the use of English idioms (e.g. "pull somebody's leg") as they may create confusion.

Rust is a new programming language building on foundations and ideas from many that came before. As such, there will probably be no one in the audience that has Rust as a first language. Please keep that in mind. Also see the section about jokes in the beginners guide if you have the feeling that these might go awry.

RustFest takes pride in being a conference that cares for people with disabilities and mental health issues. Please help us in making sure they feel welcome. See the section about ableist speech.

Ableism in talks

Let's talk about ableism. This topic is important to RustFest, as caring about people with disabilities and mental health issues is one of the points where RustFest is ahead of the curve from other conferences. Even if you might not feel like you are being inappropriate, there are a lot of speech patterns that use disability-related terms and language in a negative way.

Given that we openly care about these people by putting our Accessibility Statement out, we also (willfully) open ourselves to that critique. That extends to you, as you are the most public-facing part of the conference.

There are words and speech patterns in everyday language that are harmful to people without the speaker necessarily intending or even noticing it. Words like "lame", "crazy", "stupid", "insane", "idiot" or "crippled" refer to human mental, cognitive or physical capabilities in a negative, demeaning way. These words are often used in a metaphorical way. People use them to state their attitude towards certain things they don't like or don't agree with. If you don't see "crazy" as an issue, try to put yourselves in the position of a person that is literally insulted as "crazy" because of a condition they have and then hearing you talk.

There are good lists for replacement terms and places to read up on this article. Also, you might want to check Wikipedia for a comprehensive list of disability related terms with negative connotations, in especially if you are not a native English speaker and might not be aware that that commonplace phrase could be problematic.

Luckily, these words can all be avoided by finding clearer formulations for what you want to express: That programming language, framework, tool, algorithm or thing is not "crazy". It might be difficult to comprehend, inconsistent, wonky, or seem nonsensical at first glance, and it's okay to state that. There are imperfect things. But it is also possible to see where they stem from, and the decisions of the people who made them follow a reasoning that can be described (even if one does not agree with them).

On the other hand, try to avoid ability/health-related terms like "healthy", "normal", "sane", "intelligent", "genius" or similar to describe things you endorse. Better say "that made sense to me", "the most elegant solution to our problem" or simply state why this is a good thing.

In fact, to experienced listeners, the use of ableist phrases is a telling sign that speakers have not found a good explanation on why something is not to their liking, and just put off the whole thing by putting in a phrase they had at hand. Mind that they also insulted many people in the process, both the persons that came up with the thing they are dismissing and the people that are commonly insulted using that language.

We feel that ableist speech has been getting very little attention compared to other forms of discriminatory language, and we need to catch up on that.

Accessibility

Your talk and your slides should be accessible to as many people as possible. This is relevant (but not limited to) to people who are (color-)blind, have low vision, are deaf or have hearing difficulties, mobility impairments or cognitive disabilities. There are some very good and informative articles on accessibility topics that you can find here:

The most important points are summarized below:

  1. If you are using colors in your slides, make sure to add enough contrast. Ensure sufficient contrast between text and its background.
  2. Don’t use color alone to make critical information understandable - instead, only use color to highlight or complement what is already visible. Don't rely on sensory characteristics as the sole indicator for understanding and operating content: You should not rely solely on images, shape, size, visual location, orientation, or sound to indicate important instructions for operating or understanding content (ex. “See the image above”). Instead, use a combination of positioning, color, and labeling to identify content.
  3. If you are including images in your slides you might want to consider to give a short vocal description of the visual content, keeping in mind blind and vision impaired people.
  4. Generally, have big fonts and less content on one presentation slide, instead of small fonts and lots of information on one slide. This makes the text easier readable and the content easier to grasp.
  5. Be considerate of people with epilepsy / photosensitive seizure disorders and avoid flashing effects in your presentation.

Below you will find online tools that you can check your material with:

If you have any further questions, please don’t hesitate to reach out to us, and feel free to let us know if this guide has been useful to you or could be improved!

Subject matter, style of talks

RustFest is a community conference with many new people around, which means that speaking about your experiences with the language and your reasons behind using it trumps fine technical detail. It is a technical conference, still, so your talk can most definitely contain code where appropriate and explain it well. Also, if your project uses a clever trick or unusual pattern then, do - by all means - show it and explain it, even at the danger that some of the audience might not fully follow. Just ensure that your talk is not completely packed with those things - you are speaking to show, not to show off. Given our standard talk length, probably 1-2 of those examples are enough, with ample time for explanation. This obviously doesn't apply if your talk isn't a technical talk.

The Rust community likes arguing and writing about things in a peaceful manner. Constructing your talk as a series of arguments for your solution with one based on the other is definitely a good way to go! Make your central statements clearly visible!

All talks at RustFest (except keynotes) will be 15-30 minutes talks or alternatively 10-25 minutes with questions and answers. Please check the time slot assigned to you and let the team know as soon as possible if there are changes required.

We have a packed program, please try not to overrun.

A day at the conferences

A day at the conference can be a little bit stressful, so be prepared on what to expect. As with all other attendees, all organisers are there for you the whole weekend. Please don't keep your questions to yourself, ask for help.

Arrive at the conference early, preferably at opening. This is very important if your talk is in the morning.

This allows you to meet with the person managing the stage for final preparations: checking your slides, making sure all adapters are available, checking the microphone. It will also allow you to play through the motions before going on stage properly.

Introduce yourself to the stage host and the master of ceremonies (MC). The host will take care of of timing, notify you when to prepare to go on stage and is your first point of contact. The master of ceremonies will introduce you on stage. Give the MC the most important facts needed for announcing you (what's your topic, the proper pronunciation of your name and your pronouns). If you have any nice anecdote you like being told as an introduction, say it! MCs work with jokes, so maybe figure out something together!

If you have never given a talk before, here's a short run down of the process: please arrive to your talk early, preferably at least 15 minutes before. If your talk is the second of a set, get seated next to the stage entrance.

If headset microphones are used, please be aware of the process of getting the microphone on, as this is a common source of stress. Preferably, have one of the persons handling the stage put it on. This has turned out to a stressful moment for unprepared people, as it involves light body contact in front of the audience. Make yourself aware that it is also stressful for the person handing you the microphone. Stand upright, don't move and make eye contact with the other person, clearly indicating that you are ready to go. The other person will talk you through the process and ask you for permission before touching you ("may I put the receiver in that pocket?"). At any point during the process, feel free to do things on your own. ("No, I'd prefer to put it there myself.") Don't rush, the talk is not going to start without you.

It is also fully acceptable to just choose a hand microphone.

Familiarise yourself with the room layout, especially find out where your friends and the organisers are sitting. You might need them at some point.

Treat yourself exceptionally well during the day. This is highly individual thing, so I'm just going to tell you my view on things:

During the day, I recommend to eat lightly and not right before the talk. Stage fright is a thing and the body has the tendency to tell you that by having digestion issues. If you know you have a strong stomach, feel free to ignore that - if you never tried out, now is preferably not the best time to find out. Also, care about your water intake in the hours before the talk, stage thirst is worse then stage fright. Avoid acidic drinks.

I usually pick the shirt I wear for the day specifically for the talk and bring that in a separate bag. Right before the talk starts, I go to the bathroom, get a bit of fresh water in my face and change. This is a ritual that works for me and makes me feel better and calmer right away.

After the talk, stick around a little, people might have questions. It's appropriate to leave the after-talk discussions after some time, especially if you have to wind down. Point people to later opportunities to speak to you. Excusing yourself because you are stressed after the talk is fine. Feel free to skip later parts of the program if you feel unconcentrated after a talk.

Your time on stage

Once you are on stage, the room is all yours, except for:

  • You ask someone to help you
  • There are technical issues
  • There is no mic stand and a fellow organiser acts as one (true story)
  • You took too long

Assuming you have prepared your talk, nothing will go wrong :).

First of all, orient yourself and make sure you know where the organisers are sitting, again.

Find some faces in the crowd you like and try to speak to them.

If, against all odds, things do go wrong, internalize the following set of rules:

  • Don't excuse yourself right after going on stage. You are as prepared as you are.
  • Jokes are no way out of problematic situations and put you at risk of making things worse.
  • Jokes are a great way out of happy little mistakes and blunders.
  • If you say something you don't want to and its possibly something people might get angry about, excuse yourself immediately. People misspeak. People correct themselves. Train that in front of a mirror so that you have something handy if that happens.

The last point isn't here for show. It happens regularly that people realise on stage that something they wrote and never read in a certain way is something very inappropriate when they are on stage. The best way out is a quick and direct "never read it that way, I'm really sorry".

Make pauses. Pauses are good for the audience and for you.

Same goes for the question section: train some answers. Q&A is a great part of a talk, but sometimes, you just don't know the answer. Questions can be inappropriate, missing the point or raise a topic that needs another 30 minutes. Have standard reactions at hand:

  • "I don't know right away, I'd have to look that up."
    • That's fine, even if it is your own piece of software
  • "I cannot answer that in a minute, can we discuss that later?"

On inappropriate questions, please feel free to state how you feel. If you feel like you don't have support, make eye contact with the stage host for reassurance.

Your mentor will help you with all of those things.

Constructing a talk

I'm going to focus on the 25-30 minutes talks here. If you are an experienced speaker and have found your own talk format, feel free to ignore all of the below. If you are a new speaker, also feel free to change anything you want. Maybe someone else really inspired you with their way of constructing an argument. Note that construction and delivery is something different, a talk that is constructed in the same way can both be delivered as a funny talk or as a rant.

I usually allocate the following for 25-30 minutes talks:

  • Introduction of yourself (1 minute, preferably 30 seconds)
  • Short overview of the problem solved
  • Overview of the solution with hallmark features or findings
  • Detailed overview with interesting findings
  • Summary, outlook and review, reminding of the core ideas

The introduction serves to establish your background and how you relate to the problem. For example, if you are not a developer but instead a user of the software you present, say so. Don't turn this into navel-gazing. If you have previous works and large projects of unrelated kinds, cut any mention of them short. Also make sure you mention Twitter and GitHub accounts briefly if you want people to find you.

The next three topics merit about equal sizes of the rest of your talk. All should be somehow closed, like chapters in a book. Still, make sure you base things on each other. If you mention an aspect during the problem statement, make sure you will show a solution for it later. If you can't, it's probably better to leave that aspect out of your talk. Not every aspect has to run as a thread through the whole talk. For example, if you introduced a hallmark feature in the second part and it has a really interesting implementation detail, by all means, introduce that by the end, even if it doesn't specifically relate to the problem.

Do not only talk about the positive parts. If you struggled with something, feel free to mention that.

The final part allows you to both review the lessons learned, give outlook to the future and also bring points home that were really important. This can be as long or short as you want.

Make sure you make a good argument for what you did or intend to do!

Delivering a talk

Delivery is important for an amazing talk. If you don't feel like you are great at delivery, that's also not bad. People are at this conference to learn about technology and will be fine if you get your point across properly.

For that reason, if you feel like your talk is still missing something, it's probably not memes and jokes. Get back to the construction part. If you think your talk works well with a rather usual delivery, you may come back here.

The most important part of delivery is connecting the dots you laid out for you in a fashion understandable to the listener. If something is based on something that came before, refer back to it verbally ("Remember that our problem was connecting point A to point B through C?"). If you have a key point, make sure you hit it. Train that. You don't have to have your whole talk in your head and can probably talk about your favourite topic for 20 minutes straight anyways, but key points should not to be missed.

Your English skills will be a secondary matter. You have a story to tell and are an expert on your topic, people will appreciate you passing on knowledge.

Also, as it is a recurring issue: if you intend to joke during your talk, make sure that you can deliver it well. Rehearse. People might still not get it, be prepared for that.

On the topic of jokes, again: lighthearted talks are great and humor is cool. Mind that not everyone shares your sense of humor and you have 200 people in front of you. If you joke backfires and people don't appreciate it, or at worst insults people, you have been warned. No "I'm sorry if I offended you". This misstep is yours.

So probably jokes about current social issues are out of line, especially on a tech conference. Still, this line isn't clear cut, always be mindful of the position you speak from.

My usual recommendation here is to have jokes based on your subject matter. IT has a very special set up jokes. Finally an audience where you can make jokes about sending a UDP package from point A to point B over a point C and people might get it. Use that ability!

Never overdo it though. If you are only starting out on stage, keep it low.

Finally, swearing and curse-words. While we don't put any rules on their usage, please consider that some people find them off-putting. They might still fit your persona. Still, there lurks a danger here: if you can only make your point by using curse language, how strong is your point? Making strong statements without resorting to those tricks makes your statements more memorable. Also remember that cursing, especially about other peoples words, can quickly be disrespectful.

In my experience from over 5 years of running conferences, the clearly-stated, well-constructed, well-spoken talks with a good measure of warmth and humor are the most remembered. Of the others, I remember only the jokes.

Slide design

As weird as it may sound, I don't have much input there. Have a look at some talks around the internet - maybe you are better at connecting visual dots like images (remember those that cannot see them). Maybe you prefer just putting claims on slides and deliver the arguments verbally. Experiment a little.

Make sure that each slide is either transitioning between two of your important points or making one of those points, never both. Make sure you have some way to make clear where a topic begins and ends.

There's tons of nice ways to create slides out there. Pick one that allows you to quickly iterate on slides and change things. You might have the best idea ever 50 minutes before the talk, it should be easy to make this happen.

Don't design for later release of the slides.

Add speaker notes for slides that are not clearly understandable, though, such as bare images.

Schedule

Please check the conference's website for an up-to-date schedule. You can usually find it under https://rustfest.eu/schedule.

Travel

You can find up-to-date information about the venue and the city RustFest is hosted in under https://rustfest.eu/location/.

You should also get more information on how to directly contact the organizers in a speakers email shortly before the conference.

And of course you can always reach out to the team at team@rustfest.eu.