Iron out the process for speakers more

[RamblingCookieMonster]

When will speakers be notified?

Maybe a minimum of 2 weeks notice, with an exception for this first session, where it might be... a week? Will ping folks in individual issues)

How do you determine which demo fits in which session in which order?

Not sure if this is something we can document initially, and fifo might not always work (e.g. if we want to group topics that go well together, or separate topics that seem like they might have significant overlap)

etc.

[RamblingCookieMonster]

Related: We'll want to balance including enough demos to cover the full session (presumably we scheduled this for an hour, given the name : P) with not running over the full session length too much!

For example... if we schedule 6 demos, and each goes for 5 minutes (which is good, shorter is often better!), we'll only be at 30 minutes + overhead

But... if we schedule 12 demos, and they average 6 minutes each, we'll go over by ~ 10 minutes

I'd prefer to lean towards going over the limit, but if too many folks take their full 10 minutes, we could go significantly over an hour.

Arg : )

[GABeech]

I wouldn't worry too much about grouping things that go well together. If you think about this in the context of lightening talk type setup - part of the fun is you are hearing about a bunch of different topics that are necessarily related.

For the scheduling ... schedule 6 and if you have extra time .. uhh PS Rap Battle?

[michaeltlombardi]

My thought here is to have an agenda listed two-weeks out for future events, but for this one it might not be that much lead time.

As far as going over on the hour goes, same rules as at the conf? We're out of time, will roll you into next event?

We might want to make exceptions or handle scheduling more carefully for folks who are participating during serious off-hours.

[RamblingCookieMonster]

@GABeech good point on not worrying too much on grouping

@michaeltlombardi Yeah, rollover might be a good bet, particularly if we get the order-of-operations out ahead of time, so folks on the cusp know they might roll to the next session (being careful to not schedule folks in fun timezones in a spot that would risk rolling)

[alevyinroc]

I'll go a step further on the grouping - it's may be better to not group things at all, so that attendees get exposure to a wider variety of topics that they'd miss if they only tuned in to "SQL Server week" and "Active Directory Thursday." Sampler platter vs. buying one appetizer.

[michaeltlombardi]

My only real grouping concern is making sure we get to folks who are presenting at weird hours (middle of the night, early morning, etc) - otherwise ordering seems less important.

[wsmelton]

The timezone could be something they need to add to their submission. It can be set in GitHub or Slack profile but not everyone does that 😁 ...knowing their day hours or evening hours would help you in scheduling.

You might also note say a preference if those that can do a presentation during their work hours or those that can only do evening time frame. Just based on when you plan on holding the power hour at...as verifying connectivity and all you would likely spend more than an hour when you are up for presenting.

[brianbunke]

A thought on standby:

It works for the Summit, where we have one chance, a pre-defined block of time, and would like to cram in as many volunteers as possible.

It seems a little more unnecessary in this format. We now have to coordinate scheduling some speakers for two different dates/times, and are potentially doubling the amount of time a volunteer is committing to.

We don't have to go for an hour. If ~6 people take 40 minutes, I assume most people would be happy to get 20 minutes back. Speakers then just need to commit to a single meeting.

Less time in our lives spent scheduling and waiting = always better 😄

[RamblingCookieMonster]

I could be persuaded in that direction? If so, might prefer doing something like 8 by default (max 80 minutes, but should settle around an hour or less based on summit demo durations)? cc @michaeltlombardi

[vexx32]

I'm a fan of this approach. Should make scheduling for y'all a ton easier.

[michaeltlombardi]

Works for me! Great suggestion!

[RamblingCookieMonster]

Other things to consider:

• When do we need an ack from speakers by? GitHub notifications are painful and speakers might not see these, so might need to ping via other means
• What happens if a speaker drops out? People have lives, things come up.

[RamblingCookieMonster]

More things:

• Let speakers know what to expect (from us, and from them) each step of the way. e.g.
  • "we need a google account address to invite you to present on YouTube,"
  • "the agenda will be posted a week before the session, you can submit pull requests to update or add material for your demo"
  • "we use YouTube / Google Hangouts on Air, we'll send you the presentation link around noon of the day we're scheduled,"
  • etc.

Also, figure out what these things are (^^^^^), and when we should do them!