FOSS4G 2011 Lessons Learned

FOSS4G 2011 Home

Previous Years Lessons Learned

• 2010
• 2009
• 2008
• 2007

FOSS4G 2011 Lessons Learned

Starting this page early so we can document lessons learned as we go along where appropriate, for the benefit of future FOSS4Gs!!

Logo

We had a few misunderstandings over the logo requirements initially! This is a summary of requirements for the logo:

• It must incorporate the FOSS4G "ribbon" element, which has been used in the logo of all FOSS4G conferences. Past logos can be seen here.
• It does not need to incorporate the OSGeo logo.

The logo is something on which everyone has an opinion (often a strong one!). We recommend assigning a small group to get the logo done rather than having extensive debate with the whole team! We ended up using crowdspring and were very pleased with the way that this worked - we would highly recommend using them in future. Start on the logo asap as you need it for other early stage documents like the sponsorship prospectus.

Sponsorship

Make sure that your sponsorship benefits are a reasonable match for the previous year's, unless you have a compelling reason to change that you are willing to defend. In our first brochure we inadvertently reduced the number of conference passes provided, and quickly heard negative feedback about this from several people (in particular the fact that the bronze sponsorship included no passes rather than one). We changed the benefits to match the previous year in the light of this feedback. Also I suggest keeping sponsorship payment amounts somewhat similar to the previous year. In particular we had feedback that there should be an affordable lower level sponsorship as lots of small companies traditionally sign up for that.

We offered a 10% discount for sponsors who signed up early (by end of January for us), and this worked very well. I'd need to check but from memory, I think we had roughly 2/3 of our overall sponsorship money in by end of January, which was great.

LOC Organization

The Chair needs to get assignments made to members of the team as early as possible, and delegate effectively. I (Peter) didn't do this soon enough.

Discounts

Have discounts/comps for workshops and tutorials clearly ironed out before making any call for proposals for workshops/tutorials. This affects who and how many presenters might submit proposals and what they hopes/expectations might be. This year, our budget only stated how many free passes, generally, were available - not with a particular number set aside for workshops.

Abstract Submissions

• We allowed users to enter their name (including title) in a single box. This proved to be difficult to parse into firstname, lastname, title in order to check for multiple abstract submissions. Suggestion: have separate entries for firstname, lastname, title
• We allowed users to check multiple boxes for type of presentation (i.e. lightning, general session, etc) from which it was impossible to determine if the submitter had a format preference. Suggestion: have users select choices from a "first preference (required)" and "second preference (optional)" pick list.
• We mixed academic and general track submissions, which made the resulting datasets more difficult to process. Suggestion: Require submissions to be for either the academic OR the general track. Not both.
• Suggestion: Allow users to supply a list of keywords (such as software package, application, etc) This would help to facilitate grouping of talks when scheduling.
• Suggestion: assign an unique "abstract ID" to each abstract when it is submitted, and use it throughout the abstract voting process.
• Suggestion: State explicitly the maximum number of talks (2) on the abstract submission form.

Paper selection

With the size that FOSS4G has now reached, this is a LOT of effort, even with the community ranking system (which is a big help). Work out the "shape" of the program ahead of abstract submission closing - how many tracks you have, how many plenary sessions and how long they run, how much space for the academic track and tutorials, etc. You need to know all these things in order to know how many papers to select. Check for multiple paper submissions from the same person relatively early if possible and decide how to handle these situations. We decided that we would be open to multiple papers from the same person, but in general a maximum of two (maybe in exceptional circumstances three). We had a couple of people who submitted 5 presentations. One strategy we used was to ask the person to combine multiple presentations where this made sense (e.g. they had multiple abstracts on similar topics). Another was to see if some presentations could be given by someone else.

Events that need to be scheduled

There are several items that need to be included in the program in addition to the general presentations. We found out about some of these late in the day and it would have been easier to schedule them if we'd known about them up front. These include the following:

• Birds of a Feather (BOF) meetings - need about an hour and a half with availability of multiple rooms for groups to self-organize.
• OSGeo AGM - not strictly part of FOSS4G, but a meeting that normally happens during the conference. Also plan an hour and a half for this.
• The closing session needs to include the Sol Katz award (10 mins), next year FOSS4G introduction (10 mins).
• Web Mapping shootout - not strictly mandatory, but has been an ongoing and popular plenary session. This has traditionally been in the closing session but doesn't necessarily have to be. Need to allow 30-45 minutes for this (talk to whoever is organizing it).