Open Source Comes to Campus/Logistics: Difference between revisions

From OpenHatch wiki
imported>Shauna
No edit summary
imported>Shauna
Line 17: Line 17:
 
===== When should the event be held? =====
 
===== When should the event be held? =====
   
We usually run our events as a one-day workshop on a Saturday or Sunday, however it should be possible to split between two weekend evenings or to expand across two weekend days. Our default schedule is [[schedule | here]].
+
We usually run our events as a one-day workshop on a Saturday or Sunday, however it should be possible to split between two weekend evenings or to expand across two weekend days. Our default schedule is [[Open Source Comes to Campus/Logistics/Schedule | here]].
   
 
Generally, we find events early in the semester are better attended than events later in the semester, and fall events are better attended than spring events.
 
Generally, we find events early in the semester are better attended than events later in the semester, and fall events are better attended than spring events.
Line 24: Line 24:
 
* School calendar, if at a school. Watch out for school vacations, spring break, midterms, final exams.
 
* School calendar, if at a school. Watch out for school vacations, spring break, midterms, final exams.
 
* General holidays and three day weekends. We accidentally scheduled an event once for a three day weekend and it was very sad.
 
* General holidays and three day weekends. We accidentally scheduled an event once for a three day weekend and it was very sad.
* Season: publicity/attendance can be very hard during the summer and holiday seasons, both because students are off campus and because contacts such as mailing list admins and organization leaders/outreach officers may be on vacation. (We seem to get 75% response from mailing list admins during the school year and 0-10% response during the summer.)
+
* Season: publicity/attendance can be very hard during the summer and holiday seasons, both because students are off campus and because contacts such as mailing list admins and organization leaders/outreach officers may be on vacation. (We seem to get 75% response from mailing list admins during the school year and 0-10% response during the summer.)
   
 
===== What kind of space should we use? =====
 
===== What kind of space should we use? =====

Revision as of 21:48, 5 December 2013

This page is a collection of tips for people running Open Source Comes to Campus events. To get the full picture of what's involved in running an event, check out Open Source Comes to Campus In a Box.

Picking a place and time

What makes for a good location?

We look for:

  • Campuses with enough students to attend the event (usually 2000+) or willing to invite off-campus students.
  • Campuses either easily accessible to us or with funding to transport us to them.
  • Womens' colleges or schools with a strong Women in CS/Tech/STEM presence.
  • At least one (ideally two or three) contacts that seem enthusiastic and reliable.

If you're running your own event, some of these may not apply.

When should the event be held?

We usually run our events as a one-day workshop on a Saturday or Sunday, however it should be possible to split between two weekend evenings or to expand across two weekend days. Our default schedule is here.

Generally, we find events early in the semester are better attended than events later in the semester, and fall events are better attended than spring events.

Things to check when picking a date:

  • School calendar, if at a school. Watch out for school vacations, spring break, midterms, final exams.
  • General holidays and three day weekends. We accidentally scheduled an event once for a three day weekend and it was very sad.
  • Season: publicity/attendance can be very hard during the summer and holiday seasons, both because students are off campus and because contacts such as mailing list admins and organization leaders/outreach officers may be on vacation. (We seem to get 75% response from mailing list admins during the school year and 0-10% response during the summer.)
What kind of space should we use?

You can use this checklist to help you pick a space, and then to check out the space leading up to the event.

Reaching out to mentors and attendees

How do you communicate with staff?
  • Create a staff mailing list to help you communicate. Add your host-organizers as well, even though they are not technically staff.
    • We use mailman for our lists. I've found that it's useful to set the default response to the list, so when people respond to emails they automatically go to the full list. It's also useful to set no max limit to email size, otherwise in long threads moderators may have to process held emails left and right.
  • We recommend finding staff as early as possible (as soon as you pick a date). We try to achieve a 4:1 or 5:1 staff to attendee ratio. This is particularly important during the afternoon workshop, and we often have staff who only come in the afternoon.
    • There is a template email we use when recruiting new staff.
    • Try to find:
      • People for the career panel. We usually have 3-4 people on the panel. Here's a template email specifically describing the career panel.
      • A healthy diversity of staffers, in terms of gender and other elements of personal background.
      • People to present tutorials/lead demos/lead career panel. Can be up to 5-6 separate people, but frequently organizers will present several parts of the day.
      • What we call a "software whisperer" - at least one person who is extremely familiar with setting up development environments and working with open source software, who will be able to handle most technical problems that come up.
How do you publicize?
  • Step 1: Save the date email - if there are groups you are especially hoping to reach, it's worth sending a brief "save the date/time" email as soon as you've picked a date.
  • Step 2: Create publicity website
    • Instructions for making sites like ours are here.
  • Step 3: General Purpose Publicity
    • Once the site is made, and ideally in the time frame of 4-2 weeks before the event, we do our main publicity push. We try to reach out to:
      • The computer science department, computing clubs, ACMs, especially any diversity-focused groups such as Women In Computing groups. When doing so, we use this email template.
      • Individual science departments and clubs. When doing so, we use this email template.
      • If our hosts have given us permission, we will also reach out to students from other local colleges. When doing so, we prioritize women's colleges and community colleges, usually by emailing them a day earlier than others. You can use this preface.
How do you communicate with attendees before the event?
    • The low-effort communication strategy we sometimes follow includes:
    • The high-effort communication strategy involves, instead of sending a one-week-out form email, sending one-week-out personalized emails to attendees based on their responses in the sign up form. This strategy usually involves an extra 5-15 minutes of work per attendee but has the following benefits:
      • Attendees are much more likely to show up (our experience is that personalized emails double-triple the attendance rate.
      • As the personalized emails revolve around attendees' interests, it allows you to locate bugs for the contributions section that are especially relevant/fun for attendees.

During the event

  • Materials
    • Resources for running the event can be found here
  • Recording the Event
    • Attendance
      • Taking attendance isn't strictly necessary, but I find it useful to help match faces to the names I've been emailing. It also lets you see what percentage of sign ups showed up, and what percentage of people who showed never signed up.
      • If you have a whiteboard, a super easy way to take attendance is just to ask attendees to write their name on it. At the end of the event you can snap a picture, and transcribe later when you're less exhausted from running the event.  :)
    • Notes
      • Get as many staffers as are willing to take notes about the event. Prompts to inspire note-taking include:
        • What problems did people have? What made them seem frustrated?
        • What made people laugh? What did they seem to have fun with?
        • What questions did attendees ask? Were there any that two or more attendees asked?
    • Pictures
      • It's important that students consent to having their picture taken. We tell students at the beginning of the event that we will be taking photos and posting them online. We ask them to let us know if they're uncomfortable with that, so that we can avoid taking photos of them/delete any we accidentally take.
      • To get a high quantity/diversity of pictures we tell the staff that if they've got nothing else to do we encourage them to grab the camera and take some pictures.
      • Upload them! Right now they just go into a public folder on Asheesh's flickr account but we're hoping to get a bit fancier soon.
  • Food
    • Figure out ahead of time your food budget, and pick a place and make an order at least 24 (we aim for 48-72) hours ahead of time.
    • Because our events start early and run a full day, we like to provide breakfast, lunch, and an afternoon snack. This usually costs between $200-350, depending on the size of the event. Less, if we order pizza for lunch. Your needs may vary, but we like to get:
      • Breakfast: 1-3 boxes of coffee + milk + sugar, donuts/bagels/pastries, fresh fruit
      • Lunch: If possible, order sandwiches and salads rather than pizza. Try to provide vegetarian/vegan/dairy/gluten free options even if no attendees have listed it. Make sure to order beverages!
      • Snack: Something light (people generally aren't that hungry or are willing to eat lunch leftovers) but fruit and chocolate never hurt anyone.
    • When ordering:
      • Ask for plates, napkins, cups, and utensils (if necessary.)
      • Place the tip on the credit card you order with. If you need to adjust it, you can (presumably) do that after the fact.
      • Tell the vendor to bring things at least 20 minutes before the actual lunch time, if you have reason to believe that they might slip.
  • Helping attendees (body language, etc.)
    • Coming soon :)

After the Event

  • Follow up emails
  • Blog posts
    • We strongly encourage writing up the event and posting it on your organization's blog. We'd also love to feature posts about OpenHatch-affiliated events on the OpenHatch blog!
    • For OSCTC events, we usually make two posts:
      • A summary-type post (unofficially titled the "bug report") - see this post
      • Infrequently Asked Questions, where we answer in depth novel questions we received at each event - see this post