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
Sponsorships
Complimentary Registrations and Volunteers
Workshop Pricing
Registration
Support For Some Attendees
Scams
Discounts
Breakdown by Country
Attendance
At the Conference
Within the Conference
Within the Code Sprint
Marketing
The Mail-out
How People Heard about FOSS4G2007
Local / Regional / International
Use Proxies
Local Marketing is Key
Web Site & Program
Lists are Important
Press Releases
Social Venues
Conference Venue
Audio-Visual
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 sprit should not need to be tested though. Early preparation will avoid this to some extent.
Terminology
Call for Workshops
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
Results of the Call
Selection Process
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
Decisions
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.
Venue Type | Pro's | Con's |
---|---|---|
Large dedicated rooms at CTICC | Control! We could put in freshly imaged computers, our own LAN, good AV facilities, nice desks. Their size allowed us to hold large workshops and labs (capability for 100 pax, but max attendance was somewhere in the region of 80 folk). These rooms also acted (unintentionally) as places where folk could go and catch up on e-mail, have some quiet time, etc, when they were not in use | A little bit soulless, especially if not full. Some instructors felt un-engaged by the audience in these large venues |
Auditorium at CTICC | Ummm, an extra venue at no extra cost? | Power supply problems, network issues, cavernous place to instruct a few dozen folk. Not sure if it was a success to have a workshop where people had to supply their own notebooks - created config issues |
Hotel | This was pretty much the same as the main venues: we had control, access and pleasant environment, plus the advantage of not being too huge. Plus, tea and snacks were thrown in as part of the price. | A 5 minute walk from the CTICC, not a big problem, but causes delays |
University | The venues were a bit more intimate - instructors could engage with attendees more easily. Felt a lot less "corporate". Nice opportunity to raise awareness of FOSS4G. Lab owners were very enthusiastic and helpful | No Control! We had to work with PC's with no idea what was on them, other than the OS, and no ability to clear the environment. Who knows what students are doing on lab PC's? Network access and internet connectivity was THE major issue. The university bandwidth was limited such that one workshop in particular did not really work. Also, Internet access was controlled by a proxy, which required usernames and passwords, which the network admins were not too keen to hand out and which caused great annoyance for Firefox users. Transport to the venues was problematic, particularly if folk missed the buses |
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...
Presentations
Call for Papers
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
Submission Process
Community Ranking Process
Building Sessions
Cancellations
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#OCS_website_management
- Limitations (to be fixed for 2009):
- No list of participants easily extractable
- No online session navigation (as supported Indico, see www.foss4g2006.org)