Difference between revisions of "FOSS4G2013 Reflections by the LOC"

From OSGeo
Jump to navigation Jump to search
(Added some initial thoughts on workshops)
Line 69: Line 69:
  
 
= Website =
 
= Website =
FOSS4G web presence - did it work, what tools did we use and why
+
 
 +
The public web site was originally a WordPress (WP) site running on an Amazon server paid for by one of the LOC, WP was
 +
chosen because of some experience using it within the team. A search for conference functionality turned up a plugin
 +
that had some of the required functionality and was used to display sponsors on the site.
 +
 
 +
However the advanced functionality of scheduling talks, workshops, presentations etc didn't seem to be
 +
available from any (free) WP plugin - and we eschewed commercial solutions.
 +
 
 +
After investigating python/Django solutions, the same server was configured to run Django alongside WP, and a large
 +
amount of conference-handling code developed for PyConDE was used to manage the Workshop schedule.
 +
 
 +
A separate custom Django system was developed to handle Workshop bookings. Registered workshop users could log in and
 +
book workshop sessions - either one or two day's worth depending on what they had paid for. The system prevented users
 +
from booking overlapping workshops (and due to the different workshop lengths, this was not as trivial as preventing two
 +
bookings at the same start time). Integration with the payment system was via emailed excel spreadsheets, read in via a
 +
python script that updated the Django database.
 +
 
 +
More custom Django code was written to handle the overall timetable, integrating presentations, plenaries, breaks, and events.
 +
 
 +
Integration with an Android conference scheduling app (Giggity) was achieved - no such luck with iOS though.
 +
 
 +
Further Django apps were developed for the 'Pledge' pages and the Map Gallery.
 +
 
 +
Code for the Django apps and the WP skin were pushed to a public github site.
 +
 
 +
Post-conference, the whole site (WP, Django, etc) will be statically mirrored so it can be served from a plain HTTP server, with reduced functionality (no searching, voting, etc),
 +
 
 
== what worked ==
 
== what worked ==
 +
 +
WP worked okay as a content management system for pages. Enough of us had the ability to edit and create new pages.
 +
 +
The daily interactive timetable seemed popular - having hyperlinks between presenters, sessions, rooms etc. Icons for various highlighted talks, bookmarks etc.
 +
 
== what didn't work ==
 
== what didn't work ==
 +
 +
In the early days the site would crash under moderate load, due to MySQL dying. A watchdog script was written to restart MySQL on its demise. For the time nearer the conference the Amazon instance was upgraded.
 +
 
== what would we do differently ==
 
== what would we do differently ==
 +
 +
* Make the conference management system design a priority from day one.
 +
 +
* Use a single integrated conference management solution - payment, registration, submission, timetabling.
 +
 +
* Possibly get that solution from an external provider, the most obvious being Eldarion who develop python conference solutions based on Symposion, an open-source conference system.
  
 
= Entertainment =
 
= Entertainment =

Revision as of 02:50, 6 November 2013

This FOSS4G Cookbook documents the process, tips, hint and lessons learned by the FOSS4G 2013 local organising committee. It does not attempt to recreate the FOSS4G_Cookbook but should provide some useful pointers for future LOC's

Introduction

Information about the LOC and UK chapter

Concept

What was the aim of the LOC for FOSS4G2013? We were trying to engage with communities that traditionally saw enterprise solutions being the preserve of proprietary software and big contracts. This includes the tie in with AGI.

LOC communication

fortnightly web meetings

Face 2 Face meetings

what worked

what would we have done differently

Venue

General comments

what worked

what didn't work

what would we do differently

WiFi

Gets its own topic? or could be a sub-heading in venues

what worked

what didn't work

what would we do differently

Programme

== General == This covers the call for papers, selecting papers, organising the schedule, dealing with presenters that drop out and how the prog went at the event

selecting papers

keynotes

streams

what worked

what didn't work

what would we do differently

Merchandise

General comments on the FOSS4G branded kit (banners, t-shirts, and the stuff in the delegate packs)

what worked

what didn't work

what would we do differently

Workshops

Everything relating to the workshops,from the call, to sorting out rooms to timetables and ensuring that hardware/software needs were fulfilled

what worked

  • Presenters that took advantage of the testing sessions prior to their workshop had a much easier time
  • A number of delegates took advantage of being able to change their workshop booking prior to the event via the booking system
  • We had positive feedback regarding running workshops during the main conference
  • Providing lunch bag which delegates could help themselves to
  • Tea and coffee in the morning was appreciated

what didn't work

  • Using heavily locked down university hardware made life a lot harder for organisers and presenters
  • We where a few lunch bags short should of ordered another 10%

what would we do differently

  • Publish the schedule of workshops earlier
  • Allow delegates to book individual workshops when they register
  • Rent good spec laptops for workshops with VirtualBox installed

Academic track

Everything relating to the academic track, papers, journals, mixing the presenter in and around the main prog and academic bursaries

what worked

what didn't work

what would we do differently

Website

The public web site was originally a WordPress (WP) site running on an Amazon server paid for by one of the LOC, WP was chosen because of some experience using it within the team. A search for conference functionality turned up a plugin that had some of the required functionality and was used to display sponsors on the site.

However the advanced functionality of scheduling talks, workshops, presentations etc didn't seem to be available from any (free) WP plugin - and we eschewed commercial solutions.

After investigating python/Django solutions, the same server was configured to run Django alongside WP, and a large amount of conference-handling code developed for PyConDE was used to manage the Workshop schedule.

A separate custom Django system was developed to handle Workshop bookings. Registered workshop users could log in and book workshop sessions - either one or two day's worth depending on what they had paid for. The system prevented users from booking overlapping workshops (and due to the different workshop lengths, this was not as trivial as preventing two bookings at the same start time). Integration with the payment system was via emailed excel spreadsheets, read in via a python script that updated the Django database.

More custom Django code was written to handle the overall timetable, integrating presentations, plenaries, breaks, and events.

Integration with an Android conference scheduling app (Giggity) was achieved - no such luck with iOS though.

Further Django apps were developed for the 'Pledge' pages and the Map Gallery.

Code for the Django apps and the WP skin were pushed to a public github site.

Post-conference, the whole site (WP, Django, etc) will be statically mirrored so it can be served from a plain HTTP server, with reduced functionality (no searching, voting, etc),

what worked

WP worked okay as a content management system for pages. Enough of us had the ability to edit and create new pages.

The daily interactive timetable seemed popular - having hyperlinks between presenters, sessions, rooms etc. Icons for various highlighted talks, bookmarks etc.

what didn't work

In the early days the site would crash under moderate load, due to MySQL dying. A watchdog script was written to restart MySQL on its demise. For the time nearer the conference the Amazon instance was upgraded.

what would we do differently

  • Make the conference management system design a priority from day one.
  • Use a single integrated conference management solution - payment, registration, submission, timetabling.
  • Possibly get that solution from an external provider, the most obvious being Eldarion who develop python conference solutions based on Symposion, an open-source conference system.

Entertainment

After-skool fun.

what worked

what didn't work

what would we do differently

Timeline

The timeline from winning the bid to the event starting

August 2012

Sept 2012

During the event

Stuff that went down at the event and how we reacted to things to keep everything on track

what worked

what didn't work

what would we do differently

Parting thoughts