emacsconf-org
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Various updates, prep notes for speakers


From: Amin Bandali
Subject: Re: Various updates, prep notes for speakers
Date: Thu, 29 Oct 2020 00:21:28 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Sacha Chua writes:

>>
>> while streaming their recent FSF35 event, and it worked out pretty well
>>
> IMHO).  Would using a separate machine be an option for you Sacha, and
>> would it help reduce the multiple audio channels headache a bit?
>>
>
> My brain is the bottleneck. I can monitor text channels fine, since there's
> scrollback, but too many audio things going on would be tough. =) I can
> give it a try, though.
>

Totally fair, and no pressure. :-)  We can give it a shot, and if it
works then great; and if not, we'll stick to using the low-traffic -org
channel for orga comms, much like we did last year.

>
>
>> > +1  - Do we need another person?  Perhaps dedicated to helping with
>> > organizational comms?  I have someone in mind I could attempt to
>> IIRC Sacha handled that by herself last year, though I may be wrong (I
>> myself was in a mad scramble trying to do the stream and resolve the
>> technical issues that kept popping up that morning :-p).
>> Sacha, what do you think?
>>
>
> I'm thinking about the couple of times that we had frozen talks and the
> speaker didn't notice, because things looked fine on their end. It would
> help to have a quick way to make something go ding, since they might not be
> paying attention to the pad and IRC moves too quickly. We have
> international folks, so if someone happens to have a free or
> inexpensive way to call, that would probably beat me ringing them on my cell
> phone. I don't know if Mumble is enough of a backup for this scenario,
> since an Internet hiccup would disrupt that too.
>

Good thinking.  I agree that having an out-of-band way of reaching live
speakers would be great.  Perhaps we could tell speakers to have their
phone handy, and watch out for a short ring during their presentation,
and if they receive a call, double check their connection and/or peek
over at #emacsconf-org to see if there may be a problem.  That might
cover a good chunk of emergency situations, but it would indeed be great
if someone happens to have an inexpensive way of calling the speaker.
My only concern would be that it would have to be one of us main
organizers/volunteers, since we can't just share the speakers' info with
others.

>
>
>> > I like pushing all questions to a pad; I also like being flexible and
>> > staying out of the way of presenters who may be pulling things
>> > directly from IRC.  The only obvious danger I see would be if a
>>
>
> I'd recommend pad first, then IRC if the speaker feels confident about
> monitoring both, since the IRC conversations tend to move swiftly and go on
> tangents. IRC is great for reading the room, though. If we pull off the
> extended Q&A, there might be multiple IRC threads in the same channel. I
> wonder how we can make it manageable...
>

I agree.  And about multiple threads, I don't have much of an idea right
now, except perhaps for assigning each call a short keyword and/or
asking people on IRC to preface each question with the name of the
speaker and/or the title of the talk.  But yes, it would probably make
sense to ask people to put their questions on the pad as much as
possible.

> 
>> I think it comes down to this: will we have enough people-power to
>> stream all the extended/q&a bits outside the main track?  If yes, then
>> we don't really have to worry about having people over on BBB.  However,
>> if streaming those bits off the main track will be a challenge, and if
>> it will be much easier for the presenters themselves (or one of the
>> volunteers) to only record their desktop locally, then we would have to
>> let people on BBB to actually participate, and then we will make the
>> recording available later for those who weren't able to join in on BBB.
>>
>
> Hmmm... Actually, if speakers can stream directly to the Icecast server
> themselves, then they can talk for as long as they want, because they're
> not bottlenecked by the availability of streaming volunteers. I wonder if
> people might be interested in that... They can even do picture-in-picture
> if they want! Then the tech check involves making sure their stream
> works--they're audible and everything--and they can just hang out until
> Amin gives them the signal somehow (maybe that's where Mumble comes in? or
> #emacsconf-org or the pad?).
>
> Sacha

I think this is a cool idea, but per our discussion on IRC tonight, I'm
afraid doing so may not be as straightforward as it sounds or as one
would hope it to be.  Setting up OBS to stream to Icecast is a bit of an
involved process, and it might be asking too much of speakers to do that
and/or monitor it.  So all things considered, while I'm not completely
ruling it out just yet, I would be rather nervous delegating streaming
to speakers.  Ideally, there would only be at most one or two secondary
tracks besides the main track at any given time, so that you, Corwin, or
another volunteer could handle the streaming when the primary streamer
moves on to streaming the next talk in a different room.

Thoughts?

-amin

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]