FUDCon Live organization process

What this page is for

This is a guide for organizing FUDCon Live for a FUDCon. It is meant to be read by the organizers of FUDCon Live - in other words, they're "developer instructions." if you're an attendee at an event that has a FUDCon Live, you want to read the "user instructions" at FUDCon Live.

The remainder of this page is a DRAFT. We're working on it in gobby now. Mel Chua 16:54, 31 January 2010 (UTC)

Things that need documented:

what things in an event need to be documented, and to what level, latency, and amount of participation

• sessions
• big talks ("state of Fedora" address arguably should be videoed, etc)
  • Everything should be video and audio, but if we make it available live or not is another question.
• Mor importantly, documentation is relatively easy, you need to ask yourself before a Fedora event, how do you encourage interaction?

Parts

• Aside from the projector present for presentations, a second cheap portable projector to put up on a side wall is helpful so people can follow the IRC discussion
• A camera and microphone to record the presentation
• An onsite gobby server for local fast access to gobby
  • Contact #fedora-admin to arrange for an outgoing tunnel to a Fedora Infrastructure colo server to get outside access
• An onsite coccinella server for local fast access
  • Contact #fedora-admin to arrange for an outgoing tunnel to a Fedora Infrastructure colo server to get outside access
• A spare laptop or two in case someone needs it for transcribing (probably not necessary)
• For the one organising, bring your laptop and make sure you're connected to all the channels, by proxy if needed
  • You will want to make sure you have a complete backup of the logs in case anything goes wrong
• Clint Savage or his clone to do a good job on the A/V work
• A proxy for streaming audio and video on Fedora Infrastructure so bandwidth isn't clogged hosting those streams
• A prepared livecd or usb with the programs needed to do the necessary tasks

Before the event setup

Read through this document and familiarise yourself with the process. If possible, assist someone with this task at another event so you can see it done in action, although this is not necessary.

Before the event there are a number of processes you need to do that require interaction with several teams.

One month to one week before the event:

• Contact the local team and get a listing of rooms that will be used at the event
  • Find out what naming or numbering scheme they will use for the rooms
• Contact the organisers to find out the time format of the event (N sessions per day in M tracks)
  • Setup a table on the wiki such as this one here FUDCon:Toronto_2009_Live
• Set up IRC channels
  • Use naming scheme like #fudcon-room1 or #fedora-fudcon-room1.
  • Contact the friendly admins in #fedora-admin to get zodbot in each channel
  • If a channel is squatted, see #fedora-admin or Spot, they can resolve conflicts on Freenode.
• Find and sign up a few volunteers who will pick up slack spots in transcribing when it's difficult to find a volunteer
• Contact (who should be contacted?) to make sure the necessary A/V equipment will be present at the event.
• Contact the local team so if possible to do local dry runs of the necessary technology on site ahead of time

One week to one day before and during the event:

• Ping presenters to provide you with a copy of their slides ahead of time. Presenters always forget to submit slides after their presentations
  • You can delay publishing them until after the event, just make sure you have as much ahead of time.
• Remind presenters to ask for a volunteer to transcribe their session. Now is a good time for them to throw in a reminder in their slide deck

How to watch over the process

Wrap up process

• Getting logs
• Video
• Audio
• all into one block on a table people can look up

Providing all of the above in a similar table for real time, for sessions still in progress

Example of this is FUDCon:Toronto_2009_Live

I guess another step is to try to get as many slides up front as possible, so we don't have to worry about forgetful presenters a step by step advertisement process to get more attention, something we failed to do right, cause of time constraints

pre-event announcements

One month before the event:

According to the current FUDCon documentation, about one month before the event, the participants should start trickling in on the attendees mailing list. Put out a call for arms on the mailing list.

what you need to do to publicize the infrastructure (described above, already set up) to people to prepare them

One week before the event:

A seperate email detailing how to participate remote, sent to the attendees, fedora-list, fedora-devel, and fedora-ambassadors list

• The first three are to directly target the necessary people, the last is to target the people who can tell the necessary people

A quick blurb riding piggy back on some other announcement along the lines of (oh, btw)

One or two blog posts

At the event announcement

On the day of the event:

DUring the intro to Barcamp or other introductory processes, make an announcement about Fedora Live. Point people to the correct URL on how to transcribe documents. Put up a list of the IRC channels on a board somewhere. Put up a list of IRC nicks of people running the show. Make sure those people stand up with you briefly because sometimes people haven't put faces to names to irc nicknames yet. Present a quick slide with a short list of meetingbot commands.

Before each presentation, get zodbot to broadcast a short blurb about the next session to be run. This will let outsiders know a new session is about to begin and where. It will also leave a good demarcation in the logs between sessions.

at the event monitoring

About five minutes into each presentation, double check that there is someone transcribing the presentation. Check up on each room where there isn't yet someone doing so. Double check that the equipment is running in the rooms, doing spot checks should be ok. Double check the feeds periodically to make sure there aren't any outages. If you can, find out from people who are participating remotely if they are having any issues from remote.

At the end of the sessions, announce on IRC a reminder to keep an eye out for the survey, encourage remote users to also take it.

cleaning up logs afterwards

After the sessions, cull the information from zodbot for each channel and post links to the wiki if this hasn't been done yet. Double check that #endmeeting and #startmeeting have been called in the channels. Make sure the presenters remember to take off any microphones they are wearing so they don't accidentally run off with them still clipped to their shirts. If whiteboarding is used, make sure a link to either a series of screenshots or video is posted.

Keep a running list on who volunteered to transcribe sessions.

who to thank

At the wrap up of the event, get the list of transcribers to the Majordomo, so he can thank them. If you want to buy them a beer after the event, at a price of roughly 3-4 dollars a beer, it could cost you nearly 100 dollars. Make sure you have the cash on you if you decide to be generous. Perhaps announce you will offer a beer to anyone who transcribed more than one session.

Make a point of thanking each individual involved personally too at the after event.

survey design

And how we can do fudcon live better in the future at fudcons, based on survey results

coarse points - general results from the survey itself it seems alot of people were aware of fudcon live, but did not necessarily participate more than a quarter of surveyees were not aware of fudcon live fudcon live only hindered five people, i'm curious why docs were good, but not excellent most people think the wiki is the best distribution center people are not hot for google wave

- probably because it is non-free
- that's not true though, but it's not fully understood yet either
- well, the client is not open, true

gobby got some good attention whiteboarding too audio/video streaming needed, and whoever said that about the CCC guys (probably andreas thienemann) is 100% correct

and that puking pony could very well have been me, i did have a horrible cold after fudcon

fine points - details that are otherwise missed but also important

none identified yet

TODO:

  1.  Decide what our goals are - what do wew want out of fudcon live in the future
  2. Decide on the results we should see on the following survey - translate the above into quantifiable goals
  3. Identify changes and the expected results - put your thinking caps on!
  4. After the next event or two, see if we've made improvement - include the results in the previous half of this doc so the next person who does this isn't working on a clean slate