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.

Conference Venue

Using names of the national parks for the presentation venues sounded like a good idea but it created a lot of confusion on the first few days because the conference centre's signage obviously did include these names.

Suggestion for 2009:

• Stick to the names/numbers of rooms in the conference venue

Computers, networking

Internet traffic

The estimate from the IT service providers (ProsperIS) was that during the event the total download traffic was just under 10Gb and upload was less than 1Gb. Unfortunately we cannot at this stage get the split of the cable vs. wifi.

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.

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

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 [1].

Results of the Call

We received 45 submissions, 27 for 3 hour workshops, 18 for labs.

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 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.

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

Laptop Based Workshops

• Triple check the vmware images to ensure nothing is missing (for example, having only vi instead of vim)
• Assume a quarter of your audience will have a laptop battery life of ~20 minutes (even if you have power, think about adaptors for international audience)
• Assume you won't have wireless connectivity, and that if you do, 10% of your audience will not be able to connect to the wireless anyway
• Assume 10% of your audience will not be able to load a vmware dvd (no dvd player, unable to load vmware, etc). This means you need to have another way for them to install everything (I had other dvds with windows binaries and linux binaries and source for everything, but you know, it takes a while to build gdal!)
• If you can get an email list of attendees beforehand, have them attempt to download/install/read some stuff to get started beforehand (I realize others may disagree with this ..)
• Have 3+ presenters. They don't all need to be experts on the topic at hand - if one of them can just troubleshoot some IT issues, that will let the main presenter(s) concentrate on the core of the workshop.
• It's easier to give a workshop where there's preconfigured desktop machines :)

Obviously a lot of the above depends on the size and type of workshop it is. A GeoDjango workshop will need to probably think more about complex software dependencies and vmware images than, say, an OpenLayers workshop (though of course the latter might also need a local WMS server if wireless is not guaranteed, at the least )

See also: http://crschmidt.net/blog/326/foss4g-starts/

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

Call for Papers

Academic track

The 2008 call for papers is at FOSS4G 2008 call for academic papers

The call asked for abstracts of 500-600 words. This is a good length (better than 250 words) for making a decision on whether to invite a full paper on the academic track. However, because it is common to require abstracts of 250 words, there were quite a few submissions that were too short. Authors of early submissions were notified that their abstracts are too short and they re-submitted longer abstracts.

The blind peer-reviewed process is essential on the academic track and should not be compromised. It is also important to include a description of this process in the proceedings. Time constraints in 2008 allowed us to only peer-review the abstract and not the full paper. I would suggest that in future the full paper is also blind peer-reviewed by at least three reviewers. This will improve the quality of the academic proceedings considerably.

From the number of queries we received about publication of papers in SACJ, a peer-reviewed journal, one can conclude that this attracted authors to the academic track, especially authors from academia to whom such publications are important. It was unfortunate that the SACJ shortlist was announced after the conference. Ideally, the shortlist should be announced at the conference.

Some reviewers were confused because the 2008 conference included general GIS topics and was not restricted to open source only, and then rejected an abstract that did not mention OS. However, unless there is a joint conference again, this should not be an issue in future.

Publishing the call for papers on the wiki site meant that we could only publish the author guidelines as PDF, whereas they should be downloadable as .ODT and/or .DOC file. It makes it a lot easier to provide the paper in the correct format. In 2008 we had to attach the documents in both formats to the email notifications.

Suggestions for 2009:

• Emphasize that the academic track requires a longer abstract than the general track.
• Request 3 keywords. Not sure whether the conference system would allow this, and the keywords might have to be supplied in the Abstract text box.
• Request that the authors identify one or more of the conference topics to which their submission relates. This, as well as the keywords, will help with allocating papers to sessions.
• Allow enough time for a proper blind peer-review revision of the abstracts as well as the full papers.
• Provide the author guidelines for download as .ODT and/or .DOC file on a website.

General track

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

Submission Process

At some stage the OCS uploads stopped working, and we really had trouble in getting OCS support. In the end, we had to accept the full papers on the academic track via email, which obviously added a lot of work. After the conference, we discovered that the uploads stopped working due to a file permission error on the server, and we then had to manually upload all presentations and papers. Ideally, authors should be able to upload their full papers and presentations themselves, saving the track directors many hours of work.

Links to manuals of the conference system: [2] and [3]

Cancellations

There seemed to be less cancellations on the academic track because a submission was only included once a full paper was received. It might help to force authors on the general track to submit their presentations ahead of the conference (give a deadline). If the presentation is not received in time, it is not included in the program.

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.

Links to OCS manuals: [4] and [5]

• 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)
  • When a user's email is updated in OCS, this is not automatically reflected in the submissions of that user. There was one case where an author changed his email in his user profile, however his paper notifications were still sent to the old email address. As a track director, there is no way of knowing that the author did not receive the notification.