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.
This page should detail what things in an event need to be documented, and to what level, latency, and amount of participation they need to be documented with. It should also walk you through a process for making sure all those things get documented for an event.
The remainder of this page is a DRAFT. We're working on it in gobby now. Mel Chua 16:54, 31 January 2010 (UTC)
What does a FUDCon Live document?
When applying FUDCon Live to a FUDCon, the following sessions should be covered:
| Session | Live streaming to remotees | Live participation by remotees | Files available afterwards |
|---|---|---|---|
| Barcamp kickoff and schedule creation | Yes, high-quality | Optional | On the FUDCon schedule page |
| State of Fedora address | Yes, high-quality | Yes, IRC projected on the wall | On the FUDCon schedule page, and (edited) on Fedora Insight afterwards |
| Barcamp sessions | Yes, whatever quality is available | Yes, IRC projected on the wall | On the FUDCon schedule page |
| Hackfests | Optional | Only mandatory if you want remote participation (which we strongly suggest) | On the FUDCon schedule page |
| Other interviews/filming on the side | Optional | Optional | High-quality video edited and made available on Fedora Insight afterwards |
This page should detail what things in an event need to be documented, and to what level, latency, and amount of participation they need to be documented with.
Process
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.
Equipment
- 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