FUDCon organization process
This page is written for FUDCon organizers who have been accepted to run a FUDCon through the FUDCon bid process and documents things FUDCon organizers should think about when putting together an event. It covers the common style of FUDCon, which includes one or more days of group hackfest sessions as well as one or more days of BarCamp-style technical sessions.
Starting point: What you should already have
If you've been through the FUDCon bid process, you should already have the following:
- Sufficient time - see the schedule below.
- An local event owner/organizer (you!) with sufficient time and energy to devote to planning. You can expects to spend approximately 8-15 hours a week on FUDCon tasks until 1 month prior to the event, when that number will jump to approximately 15-25 hours per week, including meetings
- Dates for the FUDCon
- A venue for the FUDCon event itself
- A hotel location
- A general budget-availability quote from one or more sources (usually this will be Red Hat's Community Architecture team), and a contact person for obtaining access to said budget
FUDcon Team General Planning Schedule
| Local team
|| Planning team
including local leader
| FUDCon bid process begins
|Submits bid||Submit bid||Receives bids|
|Submission process ends
|FUDCon Planning FAD
- Space to lay out (in at least one line, if not two or more):
- Information kits (maps, wireless network information, lunch details, etc) you are handing out
- Any swag you are making available
- Shirts, at least one pile per size+style
- Power strips for laptops
- Wired access (temporary switches, etc) for backup to wireless access
- Video projector with VGA (15-pin sub-d input)
- Whiteboard with pens or chalkboard with chalk
- Optional but recommended: wired network access for presenter, in case wireless is swamped
- Board erasers
- Seating - various size rooms are fine, from 20 to 120
- Wi-Fi access
- Podium sign - place on podium/console or wall behind speaker so that pictures that end up on blogs/Flickr, blogs, etc as well as videos show the event name and year. 11x17" filled with the event logo is appropriate.
- Small tables with 6-10 seats (round works well), small number of
- Good network access -- consider wired as a backup/compliment to wireless
- Whiteboards or easel pads
- Map/information at front desk
- Hack room with network access and sign
- Outdoor signs advertising the event (so attendees know they're in the right spot)
- Signs to venue from parking and from transit
- Signs at venue to direct people from the entrances most likely to be used to the information/registration table
- Signs identifying room ranges and directions (Room A-E <- / Room F-H 5-8 ^ )
- Room signs to identify room (consider ignoring the existing room numbers and assigning new ones, using a numbering/lettering scheme that can't be confused with the existing one -- for eexample, Room A, B, C ... H, vs. T1106, T1109, T1113, ... T2176)
- Room signs for non-session locations (lounge, registration/information, lunch, To FUDpub)
- Session schedules - blank grid that can be filled in with the session schedule for the room once the barcamp session is finalized, and then attached to each session room door)
- Signs advertising events (FUDpub, side trips)
Include on the padge:
- The event logo
- Attendee name (in a large font size)
- Comment filled in by user (e.g., IRC nick, area of involvement, company, hiring _____)
- T-shirt size (use small font size, light coloured, or print on back to avoid embarassing anyone)
- Swag/non-swag status (e.g., eligible for lunch) - can be indicated by different-colour backgrounds
- Include any other personal-tied information on back, such as an individual wireless password
The gLabels package is a good tool for designing badges and merging in text from a CSV file. It can also shrink the font size to fit the space available for a field.
Design (for badges, signs, handouts, and so forth)
The design team is very helpful in designing preparing materials. However, there will undoubtedly be situations where the local team will need to produce materials on their own.
When designing for FUDcon, consistently:
- Use the Fedora and FUDcon event logos according to the Logo Usage Guidelines
- Use the MgOpen Modata font (from the mgopen-modata-fonts package). These fonts will work in Inkscape, OpenOffice.org, Gimp, and most other applications.
- More than 6 months in advance: monthly
- 6-2 months in advance: bi-weekly
- 1 months-2 weeks in advance: weekly
- Last 2 weeks: daily
- Use #fudcon-planning or telephone conference as appropriate.
FUDCon registration is done on-line. In the past, a wiki page was used, but we're encountering limitations in this approach -- specifically, it is hard to collect personal data (such as e-mail address, shirt size/style, and phone number) which the attendees may not wish to reveal to the world (including spam spiders). The wiki table has also grown to a width that is almost unmanageable.
Lunch has not historically been provided for the hackfest days, but could be consdered -- the loss of concentration and energy caused by organizing a delivered lunch (e.g., pizza) or going out for lunch reduces the efficiency of the hackfest.
T-shirts are typically provided to attendees, based on the size (and, ideally, style - male/unisex or female) selected in the registration system.
Fedora swag (give-aways) are typically provided for all attendees, including Fedora stickers, pressed discs, case badges, or buttons.
In order to promote early registraion, provide a "thank-you" to attendees, and to keep costs predictable, the first X attendees to register are usually the only ones to:
The value of X has varied, but has typically been around 130 people for FUDCon NA.
The swag cutoff is reached when the number of attendees that will receive swag have registered online.
The "post-mortem" meetings provide an opportunity to reflect on what worked well and should be kept for future events, and what could be improved (and how) in future FUDCons. It's a good idea to do this in two phases:
- Collect the observations of the FUDCon team immediately after the event, either in e-mail or (preferrably) by having an unwind-meeting after the event.
- Hold a post-mortem meeting after a bit of time has passed and the team has had an opportunity to reflect on the event, rest up, and hear feedback from the community -- perhaps a week after the event ends.
Immediately before and during the event, someone should be available 24 hours a day (or at least during local daytime and evening hours) via phone and/or IRC. Local team members should be assigned to cover the on-call role in shifts.