New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Program guidelines #19

Merged
merged 2 commits into from Jun 24, 2018

Conversation

Projects
None yet
5 participants
@japaric
Contributor

japaric commented Mar 30, 2018

written during the Events session at the Rust All Hands

Basically how to schedule a conference program

cc @ashleygwilliams

@badboy

Left a few comments after going through it once.

## Have a clear audience goal
Before you review talks, have a clear idea of what your target audience is. This is not just “users of the technology the conference is about”, this is also includes subgroups by field or level of expertise. Beginner talks will bore advanced users, and advanced talks will not be useful for beginners. When you have multiple rooms, having multiple targets is more feasible; however this can be tricky to schedule, so be careful.

This comment has been minimized.

@badboy

badboy Mar 30, 2018

Member

"and advanced talks will not be useful for beginners"
I think it might be ok to soften this one. There are advanced talks that can incite interest in beginners.

## Introductions
If you have an emcee, be sure to communicate with speakers about this well in advance. Ask how they’d like to be introduced — some may provide you with text, some may care less (in which case, prepare the text yourself and make sure the emcee has it well in advance). Make sure you know their pronouns, and have your emcee work with them to make sure their name will be pronounced correctly.

This comment has been minimized.

@badboy

badboy Mar 30, 2018

Member

emcee - I haven't seen it written as this, only as MC. Maybe make it more clear who that is and what they are for?

Overall, be consistent with how folks are introduced.
## Logisitics and Announcements

This comment has been minimized.

@badboy

badboy Mar 30, 2018

Member
- Logisitics
+ Logistics
## Logisitics and Announcements
A website or central document that describes the general practices and layout of the event is very valuable and can eliminate a lot of redundent questions.

This comment has been minimized.

@badboy

badboy Mar 30, 2018

Member
- redundent
+ redundant
A website or central document that describes the general practices and layout of the event is very valuable and can eliminate a lot of redundent questions.
Try to keep all the information for the event in a central and logically organized manner. Keep in mind that weird things *will* happen so have a plan for emergency/urgent announcements (anyone have an HDMI cable?) and make sure people know where to look for these. Use the same medium (twitter/Slack/IRC/etc) as inconsistancy will lead to confusion or missed announcements.

This comment has been minimized.

@badboy

badboy Mar 30, 2018

Member
- inconsistancy
+ inconsistency
- Applause (seriously)
- Plugging/Unplugging Laptops
- Speaker Introductions
- Announcements

This comment has been minimized.

@badboy

badboy Mar 30, 2018

Member

One thing we have at RustFest: Main sponsors get a 5min talk at the beginning. Might be worth to add as "Other" or something alike?

You should not only set this time aside but you should clearly show it on the program you display and distribute to attendees. They appreciate a realistic schedule and will be more likely to comply with it if they know when it is and why it’s there in advance which always makes things run more smoothly.
## Tech Check
It is extremely useful to have your A/V or organizers available to help speakers set up their machines on stage to test their display *before* they have to speak. Inevitably, not every speaker will be available (and some will flake out and forget) but every person you are able to tech check saves you time in your program and also allows the event to appear more professional.

This comment has been minimized.

@badboy

badboy Mar 30, 2018

Member

Maybe make it clear to use the breaks (morning break, lunch break, etc) for tech checks.
Also someone should be responsible in the minutes before the talk to setup speaker (mic, laptop)

Be aware of the human limitations of your participants! People get sleepy after lunch, or they may be hungover on the second morning of the event. An idea here is to have more technical talks after the coffee break and less tech heavy talks after lunch and on the second morning of the event.
## How long and how often should breaks be

This comment has been minimized.

@badboy

badboy Mar 30, 2018

Member

The "hallway track" and the breaks are often the most useful parts of a conference. We could use this section to highlight that.

Program guidelines
written during the Events session at the Rust All Hands

cc @ashleygwilliams
@deg4uss3r

This comment has been minimized.

Collaborator

deg4uss3r commented Mar 30, 2018

Updated suggestions from @badboy

@badboy

This comment has been minimized.

Member

badboy commented Apr 11, 2018

#16

@skade

skade approved these changes Apr 14, 2018

## Introductions
If you have an emcee (MC), be sure to communicate with speakers about this well in advance. Ask how they’d like to be introduced — some may provide you with text, some may care less (in which case, prepare the text yourself and make sure the emcee has it well in advance). Make sure you know their pronouns, and have your emcee work with them to make sure their name will be pronounced correctly.

This comment has been minimized.

@skade

skade Apr 14, 2018

Contributor

I'm thinking if dealing with speakers (before and during the event) merits an own document for cross-referencing?

This comment has been minimized.

@badboy

badboy Apr 14, 2018

Member

We could definitely expand this into its document.

If you have an emcee (MC), be sure to communicate with speakers about this well in advance. Ask how they’d like to be introduced — some may provide you with text, some may care less (in which case, prepare the text yourself and make sure the emcee has it well in advance). Make sure you know their pronouns, and have your emcee work with them to make sure their name will be pronounced correctly.
Some speakers feel awkward about self-introduction, so having an emcee introduce them can be quite helpful. Others may have a talk that starts with an introduction that segues into the material, so they may wish for the emcee introduction to be shorter.

This comment has been minimized.

@skade

skade Apr 14, 2018

Contributor

👍

We don’t recommend opening the floor to Q&A. We do recommend:
- Dedicated room/Speaker Corners
- Keep it short, speakers want to go to talks too!

This comment has been minimized.

@skade

skade Apr 14, 2018

Contributor

I agree that most Q&A's are bad, but I don't know if I fully agree with the recommendation. I don't know about how to phrase it better :/.

There's also moderated/submitted Q&A, where questions have to be submitted to the MC, who will ask them (or not). This also ensures that the Q&A is no essays in themselves, as people cannot submit more then 2-3 sentences.

This comment has been minimized.

@badboy

badboy Apr 14, 2018

Member

Yeah, we should rephrase that to list the options instead of excluding Q&A in total. I will think about the phrasing later.

@badboy

badboy approved these changes Jun 24, 2018

- Have a microphone for the audience for immediate questions afterwards
- The MC should be around and stop people without an actual question
- A moderated Q&A, where questions have to be submitted to the MC, who will ask them
- Collect from Twitter, IRC channel, etc. or dedicated website

This comment has been minimized.

@celaus

celaus Jun 24, 2018

Collaborator

When recording/live streaming the speaker/MC has to repeat the question when there's no microphone for the audience.
When live streaming a "no presence required" way of asking questions is very appreciated

@badboy badboy merged commit 10873eb into master Jun 24, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment