FOSS4G2008 Lessons Learned

Back to Conference_Committee

This page is a collection of information, comments, and suggestions, based on the planning, organizing, and hosting of the FOSS4G 2008 conference. The intent is to provide a resource that can be used by organizers of future FOSS4G conferences. This is not a forum for conference attendees to comment on the conference. Use FOSS4G2008_Comments for that.

= Bidding =

= Timetable =

= Money =

Workshop Pricing
= Registration =

Within the Code Sprint
= Marketing =

Press Releases
= Social Venues =

= Conference Venue =

Quirks
= Accommodations =

= Transportation =

= Workshops and Labs =

Workshops and labs were again very popular. In Cape Town, it presented a chance for many people to shake off their fears of working with FOSS. There is some talk of not running the 1.5 hour labs in 2009. Consider that some of the labs had over 70 people attending. There is certainly a demand. This needs to be balanced though. 2008 had too many workshops and labs - 15 workshops and 20 labs in total. This became difficult to manage logistically and technically - there are so many factors that can go wrong!

Workshop Committee
This is a big task, even if at 2009, Sydney decides to scale back on the workshops and labs.

We had it roughly break out as follows:

A person responsible for the technical side of the workshops and labs (software, computer setup etc) A person responsible for the logistical side (comms with the IT suppliers, other suppliers) Advisor from 2007/ OSGeo 2008 Conference Chair, to ensure integration with the rest of the conference

For the scale of 2008, we probably needed another LOC member technically involved.

We used formal conference volunteers to an extent, but if we had more more of them, they could have been put to work quite happily on doing tests and installs.

The amazing part was the willingness to help out evident in the FOSS4G community. A gang of helpers made sure that we were all systems go for Monday by spending most of their Sunday helping to install, configure, test stuff. No complaining, just doing. Brilliant! Ideally, this spirit should not need to be tested though. Early preparation will avoid this to some extent.

Timing
As early as possible to allow maximum time for instructors and workshop committee to prepare (though some instructors will always leave things to the last - human nature!). It should go out in a month or two's time from now - preferably before year end.

Format of the Call
We put out a document in pdf, odt and word that required instructors to fill out a bunch of info that would help us to assess the session. Best to read it at.

Results of the Call
We received 45 submissions, 27 for 3 hour workshops, 18 for labs.

Philosophy
Do you want to cater for the most established projects, in the hope of filling up rooms, at the risk of becoming stale? Do you wish to introduce new software tools to the audience and give a chance to emerging projects? Well, a mix of both seems appropriate, but one has to judge the potential audience a bit. For Cape Town we had local knowledge, for example, that MapWindow GIS was gaining some popularity in certain circles. As a result, we made sure that this project had several slots in the programme. The risk of having less well known projects as workshops is that attendance might be lower, affecting the conference bottom line. Labs are an opportunity to showcase such projects.

Ranking and Decisions
Google Docs was a neat way to do things. We each ranked each proposal on a scale of 1 to 5, based on importance to the FOSS4G community, likely interest, likely audience size and stated requirements, We added comments and then compared scores, imparted some local knowledge and gave an initial rank sort. We also considered whether some of the workshop proposals could be undertaken as labs.

Ot of this came a second rank, which ended up close to the eventual program. Instructors were then invited and given time to consider how serious they were about participating, which included registering on the conference site. Some on the list pulled out and were replaced from the next in line from the rankings.

Communication with Instructors
Instructors should be *forced* onto the workshop-dev mail list - at 2008, some instructors did not join the list and were a bit incommunicado. Personal communications cannot be underestimated too.

Preparation Process
Actually there is probably some sense in having a few stages to the workshop/lab development process. Probably difficult to do, but perhaps ensure that the material to be presented (software, data, printouts, slides etc) are ready at least a month before the time. Some projects want to show the latest and greatest features at the workshop or lab, but this creates stress and risk. We had workshop / lab presenters compiling their code for their session the night before. All in the spirit of things, but very stressful indeed. Avoid. Determinedly.

Venues
At Cape Town, we had 2 big, dedicated venues at the main conference centre plus the main auditorium for one workshop, one venue at the hotel where most delegates were staying and two venues at the University, 15 minutes drive away.

The logistical and control hurdles of having workshops at a University were big. Much better to keep venues in one place if possible, or otherwise have them in close walking distance of each other. There is a lot to be said for having 'clean' venues, where you have control over how things work. Try to encourage more interaction through careful choice and setup of venue

Computers and Networks
Rule number 1: Work with a good technology supplier. We had the most amazing experience with our main IT suppliers - they were flexible, helpful, committed and technically sound. Okay, so the bandwidth was used up at times, but that had more to do with the cost of connectivity than the IT team.

Our approach was to allow several ways to present a workshop or lab. Instructors could build a LiveDVD / LiveUSB and run the session from that. Alternatively, instructors could prepare a VMWare image and run the session from VMWare Player. Thirdly, and most commonly, instructors could provide some software (and data) and provide setup instructions. We then ran through the setup on 2 slightly different machines, and then our IT supplier imaged this setup over the 98 other machines.

The LiveDVD/LiveUSB approach worked pretty well, putting all the onus onto the instructors to be ready. this approach incurs a higher hardware cost, as one needs more RAM.

The VMWare approach was mixed. It was most successful when a thin Linux image was used. Windows based images were huge, and thus difficult to upload/download in preparation. Also, the VMWare approach definitely requires more punchy machines - minimum 2Gb RAM. With enough preparation time and upload/download bandwidth, this is a very solid approach though one needs to be careful to make sure networking is setup properly.

The third approach worked well on the whole. We could prepare the environment quite well if instructors came to the party early with their requirements and instructions. One thing that we tried to a limited extent was opening up a VNC/Remote Desktop Connection to the machines that we were preparing. Given more time, we could have had a slot where each instructor made sure that their setup worked. Agreement on port numbers beforehand was useful for this approach. This approach came a bit unstuck when instructors were not prepared well in advance. Installing a bunch of software across 50 machines the night before a workshop or lab is not conducive to good heart health. If this approach is followed, one thing that worked really well was having an identical network share on each machine. This allowed us to rapidly install software in-situ through an almost peer-to-peer method.

Whichever approach is followed, it is well worth having a conference Server, where last minute things can be served from, whether they be a patch, a set of data or a set of documents.

Software
We ran Windows XP as a base install. This worked quite well for the South African environment and for the particular conference, which included a lot of folk who were less exposed to Linux. I feel that this choice was determined by our audience in the end. Some FOSS4G attendees were annoyed by the use of Win XP in this way, but it was a pragmatic approach that worked, and also allowed certain FOSS4G projects that are Windows based to gain exposure. We needed to introduce many people to FOSS4G, not necessarily the whole FOSS universe out there. Perhaps the audience will be different in Sydney, but the choice does need to be carefully weighed up. We chose to offer a bridge into FOSS for the most people.

MS4W, OSGeo4W, PostGIS, Java, Tomcat, Firefox, Google Earth covered a lot of bases and were all easy to install and work with on Win XP.

Printed Handouts
2008 provided printed handouts where instructors wished them to be provided. One issue is that for labs it is difficult to know how many to print, for the labs are essentially walk in affairs. Feedback from attendees at labs and workshops suggests that, on the whole, printed material is desirable. One downside to having printed material is that attendees often tend to race ahead of the instructor, which can be problematic if the workshop or lab content is complex or likely to cause problems if an attendee misses a step.

We found a very helpful professional printshop near (i.e. 2 minutes walk) to the conference venue. They were flexible, accommodating and very professional. We organised a kind of printing "slush fund" at the printshop, which was capped at a certain level.

On another track, printed material offers a sponsorship opportunity...

Evaluation Forms
We provided evaluation forms, in paper format, for all workshops and labs. However, the use of paper forms has to end - it requires someone post-processing each and every one to convert to some digital format for sharing. A web form/survey could be used, since all workshops attendees are in front of a computer anyway. I think this is a must for 2009.

= Presentations =

Academic track
The call for papers did not include a request for number of words. This lead to some minimalistic, say useless, abstracts for the proceedings. A reasonable abstract and 3 keywords will also help to categorise the submissions more easily for the individual sessions.

Suggestions for 2009:
 * abstract number of words (300-500 words + 3 key references)
 * request 3 keywords

General track

 * abstract number of words (150-300 words + optionally 3 key references)
 * request 3 keywords

Posters
= Wiki =

= Conference Evaluation =

Workshop Evaluations
= Onsite Staff =

= Program handouts etc =


 * convenient small flyer, nice to carry around
 * presenter names would be desired (small font)

= Conference website software = For the first time, OSGeo is making use of the Open Conference Systems (OCS) software to 'manage' a FOSS4G conference.


 * See FOSS4G2008_Site_Upgrade
 * and FOSS4G2008_Committee_Issues
 * Limitations (to be fixed for 2009):
 * No list of participants easily extractable
 * No online session navigation (as supported Indico, see www.foss4g2006.org)