FOSS4G2013 Reflections by the LOC

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

LOC Members
The list of responsibilities against each team member gives an indication of the main lines of responsibility only, almost everyone pitched in on much more than their allocated tasks

Steven Feldman, Chair - sponsors, finance, keynoters, program Jo Cook, Deputy Chair - web, liaison with OSGeo community, giveaways, ice-breaker Jeremy Morley, Deputy Chair - liaison with university, technical stuff for workshops, program, gala night

Abigail Page - programme book, volunteer organiser

Addy Pope - educational bursaries, ice breaker

Antony Scott - communications, web site, signage, programme book, gala night

Barend Köbben - academic program, cartography, programme

Barry Rowlingson - web design and development, online programme, workshop registration system, map gallery, gala night

Claire Gilmour - organisation, organisation and organisation, registrations

Franz-Josef Behr - academic programme

Ian Edwards - hackathon, OSGeo Live DVD's, liaison with UK Chapter

Ian Holt - workshops

Kenneth Field - Opening up the Map competition

Mark Iliffe - workshops, closing party

Matt Walker - workshops

Peter Batty - OSGeo Board representative and dispenser of calm wisdom

Rollo Home - programme coordinator, communications

Suchith Anand - academic programme and educational content

UK Chapter
IE and SA are both active within the UK Chapter. Several other participants in the UK chapter were volunteers at the event.

Lessons learnt (chairman's perspective)
1. you need more people for more time than you can possibly imagine before you start so try to get extra people involved

2. people volunteer with the best of intentions but then life/the day job intervenes so try to get double cover for every role

3. everyone will surprise you

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

Our key objectives were:
 * a gathering of the OSGeo community
 * outreach to current and potential users of open source geo

These objectives were encapsulated in our conference strap line "Geo for All"

There is a potential conflict between these objectives and developing a program for both was sometimes a challenge. Difficult to judge whether we got it right

=Pricing=

Pricing for FOSS4G is enormously contentious.

Full conference package prices were set at $600 including local sales taxes as indicated in the call for proposals. We were criticised by some people for being too expensive and for not offering free places to project developers, workshop presenters, people from the developing world etc. Prices were set to cover the direct outgoings associated with each delegate plus a small contribution (20%) to general expenses.

One sponsor supported an academic bursary scheme which enabled a number of students to attend the conference if they could raise the cost of their travel

All of the surplus from the conference comes from the high level of sponsorship that we received (a fair proportion coming in during the last 3-4 months) it would have been difficult to anticipate this level and use sponsorship income to further reduce delegate prices early on. FOSS4G 2013 will contribute over $150,000 to OSGeo and the UK Chapter, this is currently the principal source of funding for OSGeo, perhaps the conference messaging should explain that better.

The OSGeo Board failed to provide clear guidance on pricing and profit objectives which left the conference team in the predictable firing line.

= Communications = Look at internal and external communications

Basecamp
We decided to use 37Signals Basecamp for our internal communications in preference to some combination of public and private mail lists and a wiki.

It worked well providing a repository for all of our meeting minutes, to do lists, over 400 discussion threads, nearly 100 collaborative text documents and 300 files. The cost of the subscription was donated by an early supporter but most of the team found it an easy and productive way of tracking all the different threads and activities

From a chairman's perspective basecamp provided a quick way of monitoring numerous delegated activities

fortnightly web meetings
For most of the year leading up to the conference we had a fortnightly team call on a Friday afternoon from 2.00 to 3.30pm. In the last 3 months we increased the frequency of the calls to weekly.

The calls were held via webex thanks to initial support from Sustain and subsequent provision by the Met Office. webex is far from ideal as those trying to connect from linux, android and apple devices discovered! However overall it provided a better environment than a simple conference call service and we pretty much learned how to make it work.

On a typical call about half the team participated. A few people frequently found it difficult to participate in the calls due to work commitments which was a problem but the organisation of FOSS4G needs to factor in volunteer availability. The regular team calls played an important role in bonding the team together.

Face 2 Face meetings

 * Day long face 2 face meeting in Nottingham in Sept 2012 immediately after the close of the UK OSGIS event. We got to walk round the site and get a feeling for how things might work


 * 2 day meeting in Nottingham to work through programme selection and scheduling and most of the other planning


 * Day long face to face focussing on logistics with the deVere team 2 weeks before the event started


 * Final day long face to face to write this wiki, approve accounts and debrief with board rep

Face to face meetings are more productive than conference calls but they incur cost for travel and over night accomodation

Web site
''do we have any stats on web site logs? BR/JC?''

what would we have done differently
= Venue = General comments

what would we do differently
= WiFi= Gets its own topic because it is so so important. This was a tech event with over 800 delegates per day (most sucking up 2 connections for phone and laptop or tablet) where the wifi stood up throughout. We even managed to cope with the launches of iOS 7 and QGIS 2.0 during the conference which must have boosted the download rate.

We paid a contribution of £5,000 specifically to get the internet pipe and router infrastructure upgraded. That works out at approx £6.50 per delegate.

what worked
Just about everything except for 1 router on day 1 which gave some users a problem. Having a dedicated technician on site for the first day helped to solve the problem and gave us a lot of reassurance.

what didn't work
Nothing that I can think of

what would we do differently
Nothing that I can think of

Advice to future FOSS4G organisers
Most venues do not have enough bandwidth or access points, consider paying for extra if you can

= 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

streams
Note  that we did not include a separate "Academic" Track or stream (see also section and Academic Track). This was different from earlier years, and was decided on quite early in the process. This was done on purpose, so as to not create an isolated, exclusive, part of the conference, but instead to generate attention for academic input in the community and to cross-pollenate with industry, developers and users.

what would we do differently
= Merchandise = General comments on the FOSS4G branded kit (banners, t-shirts, and the stuff in the delegate packs)

what would we do differently
= Programme Booklet = The work on the programme book was outsourced to Barry Hall, a designer that had been recommended to the team. Barry produced a couple of suggested layouts and then used feedback from the team to work up an agreed look. General text for the booklet was written in a Google Doc and shared with the whole team for editing, before been finalised and sent to Barry. A link to the online programme was provided to Barry to use to take this text across.

A mini / lanyard version of the programme was also created to allow delegates to leave the booklet behind and still follow the timings if they needed to. This had links for delegates to access the sessions descriptions online.

Despite the design being outsourced, this is still a major task for a member of the team and it is difficult to oversee this when involved in other activities. A lot of the work happens close to the final event arrangements. This is important to consider when assigning this to someone.

(note to self: need to add in something about timescales I think, when did we start, when did we have to sign off on this etc for future ref).

what worked
Outsourcing the design work Having one member of the team work directly with the designer to provide clear instructions Assigning a couple of team members to write up and generate the general text instructions Having a few keen proof readers to provide valuable input

what didn't work
Timescales were a bit tight Giving the designer a log-in to the basecamp platform, there was too much there and difficult for him to quickly follow threads

what would we do differently
Start collating the text for the booklet earlier This would allow more notice for those that were being asked to provide content (welcomes, adverts..) Glitch with the link to the online programme meant it all had to be imported a second time - more careful checking of source information (we were all tired by this point...)

= 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, those that did not received harsh feedback
 * Workshops that used writable LiveUSB went down well with the delegates
 * 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

 * Some delegates complained that the schedule did not provide a progression from intro to advanced
 * Using heavily locked down university hardware made life a lot harder for organisers and presenters
 * The university proxy was a challenge for some
 * 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
 * Look to schedule intro workshops before advanced if possible
 * Rent good spec laptops for workshops with VirtualBox installed
 * Encourage all presenters to submit either a VM or USB/DVD prior to the event with instructions for testing

= Academic track=

In 2011 a Memorandum of Understanding was signed between OSGEO and the ICA (International Cartographic Association). The purpose of this MOU was to establish a collaborative relationship between the two parties, sharing the goal of developing on a global basis collaboration opportunities for academia, industry and government organizations in open source GIS software and data. One of its action points was for the "ICA Commission on Open Source Geospatial Technologies to help OSGeo to establish a framework for publications for the academic track of FOSS4G conferences." Barend Köbben, member of that ICA commission, volunteered for that task at the time of the ill-fated Beijng FOSS4G in 2012, and carried that over to the Nottingham 2013 conference. Our suggestion is to keep this effort going, and we therefore are offering the Portland 2014 team our services to share experiences and coordinate the effort with the Portland LOC (it's is our understandanding that Eli Adam and David Percy would be their AT contacts).

We made an open call for deciding the Academic track chairs to ensure we get the best candidates who have interest in this applying (not just the LOC members) and the LOC chose 2 academic track chairs from the Expressions of Interest. This has proved successful in attracting the best talent. This was also based on the ICA-OSGeo MoU actions that ICA Commission on Open Source Geospatial Technologies support the Academic Track of FOSS4G. We are pleased that this model worked successfully and we hope the future LOCs will also consider this approach.

Academic institutions and scientist are always have been part of the audience of FOSS4G conferences, whether it be by as developers of the open source software, as collaborators in the design of open standards, in the dissemination of open source by education, or in the collection and the hosting of freely available geo--data.

The FOSS4G 2013 Academic Track was aimed at bringing together researchers, developers, users and practitioners carrying out research and development in the geospatial and the free and open source fields. With the Academic Track motto "Science for Open Source, Open Source for Science", the organisers tried to attract academic papers describing both the use of open source geospatial software and data, in and for scientific research, as well as academic endeavours to conceptualize, create, assess, and teach open source geospatial software and data. There was an effort to specifically attract contributions from "early stage researchers" (PhD students, PostDocs) to give them an opportunity to aim for a high-ranking publication and present their work to a large audience of focussed professionals.

Note that we did not include a separate "Academic" Track or stream in the actual presentations programme. This was different from earlier years, and was decided on quite early in the process. This was done on purpose, so as to not create an isolated, exclusive, part of the conference, but instead to generate attention for academic input in the community and to cross-pollenate with industry, developers and users.

Software used: Open Journal Systems
For the FOSS4G2013 conference we used separate systems: WordPress for the main conference site and the presentation and workshops tracks (see below) and OJS (Open Journal System) for the Academic Track. Both were installed on the same Amazon instance. The reason there were separate systems was pragmatic. By the time we had to start the AT timeline no choice had been made for the main conference system. We knew we'd need a rather elaborate system for the AT, to keep track of many reviewers, authors and papers, and at the same time keep the review process double-blind (i.e., authors and reviewers remain anonymous to each other). There are a multitude of possible solutions, both commercial and open source, and a suitable open source one seemed Open Journal Systems. Additionally, one of the AT chairs (F-J Behr) had experienced OCS, the somewhat simpler version of the same software, as well suited for that particular task, so we decided to use it.

Call for Papers and selection process
The original call for papers can be found here: http://2013.foss4g.org/academic-track/call-for-papers/

We invited academics and researchers to submit full papers in English, of maximum 6,000 words, before the deadline (see timeline below). Templates for submission in a variety of formats (OpenOffice, MS Word and LaTeX) were available [see http://2013.foss4g.org/ojs/static/FOSS4G2013_templates.zip], and detailed requirements, regarding layout, formatting and the submission process, could be found on the FOSS4G 2103 Academic Track submission pages at http://2013.foss4g.org/ojs/

The Academic Track committee was made up of Academic Track Chairs:

Barend Köbben (ITC, University of Twente, Netherlands) – b.j.kobben@utwente.nl   Franz-Josef Behr (Stuttgart University of Applied Science, Germany) - franz-josef.behr@hft-stuttgart.de and the following reviewers, a committee of experts in the field, who were asked to assess the papers on originality and academic rigour, as well as interest for the wider FOSS4G community. The full list includes the following people (who we'd like to thank again for their hard work):

R. Jaishankar (Indian Institute of Information Technology & Management) Eric Grosso (Institut Géographique National, France) Stefan Neumeier (Johann Heinrich von Thünen-Institut, Germany) Didier Leibovici (University of Leeds, UK) Rafael Moreno (University of Colorado Denver, USA) Homayoon Zahmatkesh (Tehran University, Iran) Gregory Giuliani (UNEP GRID, Switzerland) A.P. Pradeepkumar (University of Kerala, India) Brent Alexander Wood (Environmental Information Delivery, New Zealand) Peter Löwe (German Research Centre for Geosciences) Helena Mitasova (North Carolina State University, USA) Matthias Möller (Beuth University Berlin, Germany) Muki Haklay (University College London, UK) Hans-Jörg Stark (University of Applied Sciences Switzerland) Simon Jirka (52North.org, Germany) Maria Brovelli (Politecnico di Milano, Italy) Rolf de By (ITC, University of Twente, Netherlands) Serena Coetzee (University of Pretoria, South Africa) Ivana Ivanova (ITC, University of Twente, Netherlands) Charlie Schweik (University of Massachuetts, Amherst, USA) Tomasz Kubik Wroclaw (University of Technology, Poland) António J.F. da Silva (Universidade Nova de Lisboa, Portugal) Anusuriya Devaraju (IBG3-Forschungszentrum Juelich, Germany) Philip James (University of Newcastle, UK) Claire Ellul (UCL, UK) Jorge Gustavo Rocha (Universidade do Minho, Portugal) Tuong Thuy Vu (UNMC, Malaysia) Thierry Badard (Laval University, Canada) Kathrin Poser (GFZ Helmholtz-Zentrum Potsdam, Germany) Songnian Li (Ryerson University, Canada)

(A list of contact emails is available upon request from the chairs)

There was a two-step (double-blind) reviewing process: First a review of the full papers, in which the reviewers were requested to judge papers on their suitability for presentation, and publication in the proceedings in the on-line OSGEO Journal [1]. And from this selection the reviewers were asked for suggestions for papers to be published in Transactions in GIS [2]. We expected to select 20-25 papers for presentation and publication. We considered the OSGEO Journal to be an approprate outlet for the conference, as it is the OSGEO's "own" journal and is focussed on Open Source for Geo and thus fits very well the subject matter. But we also recognised that to attract high quality papers, in the current academic climate of "publish or perish", you have to also offer the possibility of publishing in a journal that has an recognised international academic ranking. We fortunately could come to an agreement with the editors of the journal "Transactions in GIS" to offer some 5-8 slots for inclusion in a special issue of the journal. In principle, the editors of TGIS have agreed to do this again next year(s), if both parties are satisfied with this years' outcomes.

The OJS can be used to do all steps necessary in the process: inviting and keeping track of reviewers, submission by authors, keeping track of reviews. We invited three reviewers for each paper. Reviewers could use the OJS to add comments to authors and to editors separately, and they could rank the paper:
 * Strong Accept and recommendation for inclusion in Transactions in GIS
 * Strong Accept
 * Weak Accept
 * Reject

The rejected papers were either fully rejected (some being totally out of scope, others way too long, some just plainly bad quality), or in a limited number of cases were deemed to be interesting, but not suited for academic publication: these were referred to the "normal" presentations track.

Reviewers also could state if they wanted certain revisions to be made before accepting the paper. All of this is nicely tracked in the OJS system, emails are generated and sent, etcetera.

After revisions were done by the authors (where necessary -- here again OJS is of great help to track things) the AT chairs did the final selection: Out of a total of some 35 submissions (a slightly disappointing number), we accepted 19 papers. Out of these 5 publications were recommended for inclusion in the Transactions in GIS journal, which thus left 14 to be published in the OSGEO Journal.

[1] -- OSGEO Journal, the official Journal of the Open Source Geospatial Foundation; http://journal.osgeo.org/index.php/journal [2] -- Transactions in GIS. Published by Wiley; included in ISI, with an impact factor of 0.54; Edited by John P. Wilson, David O’Sullivan and Alexander Zipf. Print ISSN: 1361-1682 Online ISSN: 1467-9671. http://eu.wiley.com/WileyCDA/WileyTitle/productCd-TGIS.html Transactions in GIS. Published by Wiley; included in ISI, with an impact factor of 0.54; Edited by John P. Wilson, David O’Sullivan and Alexander Zipf. Print ISSN: 1361-1682 Online ISSN: 1467-9671. http://eu.wiley.com/WileyCDA/WileyTitle/productCd-TGIS.html

Time line
We set up a time line so as to try to have the selected papers published by the time of the conference. For this is was necessary to make appointments with the editors of our two outlets (see above) on dates.


 * December 2012: Submission open at http://2013.foss4g.org/ojs/
 * 22 February 2013: Deadline for submission of full papers
 * 1 May 2013: Reviewing decisions
 * 19 May 2013: Paper revision deadline
 * 15 September 2013: publication of selected papers; 8-10 papers in Early View (on-line) Transactions in GIS; others in on-line OSGEO Journal
 * 17-21 September 2013: FOSS4G Conference
 * early 2014: printed issue Transactions in GIS

It transpired that even when starting the process very early, this was only just do-able: In the end the papers in Transactions in GIS were published on-line (as "early Preview") at the time of the conference (and will appear in printed form as a special issue somewhere in Q1 of 2014); The OSGEO papers were accepted and have been uploaded, but are not published on-line yet (also expected Q1 2014).

what worked
The experiences with the OJS software were largely positive. It was very stable, is flexible (if somewhat daunting to start with) in the way it can be set up. For a next conference we'd probably want to tweak it a bit further, but in general it served us well, and allowed us to keep a grip on the process.

Mixing the "Academic" presentations inthe "normal" programme worked well to generate attention for academic input in the community and to cross-pollenate with industry, developers and users.

what didn't work
We were disappointed by the actual number of submissions. Luckily the quality was generally high, so that we ended up with enough positive reviews to fill the track. But it is clear that for a broader/safer selection, we should have done more to attract submissions. Sending out emails, publishing on websites, tweeting and other social media come to mind (aimed at academic organisation, OSGEO chapters, GIS organisations, GIS publications, etcetera).

what would we do differently
The reviewers that had accepted originally, did not all react (in time) when asked to do the actual reviews. The list we included above are those that actually did review, the original list was a bit longer. It became clear that you need some "reserve capacity" here: Our advice would be to at least ask four reviewers per paper, to be reasonable sure to have three or at least two reviews in the end per paper.

The final stages of publication were not agreed upon clearly enough with the OSGEO Journal. We should have made clear agreements with the journals' editors as to who does what: Now, when we finally sent all the edited papers, it was not clear who was going to to final copy-editing and proofs. This has resulted in a delay of publication that could have been avoided.

= 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 would we do differently
= Volunteering =

what would we do differently
= Timeline = The timeline from winning the bid to the event starting

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

what would we do differently
We should have better pre-organised/structured the registration process: The papers were not in any clear order, so when things got crowded the registration volunteers had a hard time finding the appropriate badges/packs. Simply having separate piles for alphabetic groups (as seen in many conferences) would have simplified things a lot.

= Parting thoughts =