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, merchandise, 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

Interaction from the OSGeo Board

To be frank, we didn't have a great deal of public support from the board throughout the organisation process, although Peter Batty was very supportive as our board liaison. We attracted criticism on a couple of issues that should be the responsibility of OSGeo rather than the organising committee for a given event. These could have been explicitly specified in the Request for Proposals, or at least responded to when they came up on the discussion lists.

Issues that should be the responsibility of OSGeo:

Whether workshop presenters get free passes to the event

We would have been happy to do this, but it should have been included in the request for proposals so that our costings took this into account.

Whether key project developers get free passes

Again, this should be specified in the request for proposals. Which projects should qualify? (Only those that have been through incubation, all OSGeo projects, all Open Source Geo projects...). How many developers should get a ticket? Who decides who gets a ticket? It's a commonly quoted myth that it costs nothing to give someone a free ticket, when in fact we incurred a cost of XXX per delegate.

The setup and manning of the OSGeo booth

This was raised early on in the process and at several occasions after, with very little response until the last minute, when it was expected that the local chapter would provide the manpower and booth decoration. The OSGeo Board should coordinate the organisation of this- asking the local chapter where appropriate. However bear in mind that the local chapter are likely to have enough on their plate as part of the main conference organisation. The local chapter can coordinate the production of OSGeo Live DVDs, display materials and so on but this should not be left to them to make the decision about what's required, or the financial costs.

WMS Shootout

Again this was raised early in the organisation process, with very little response until the last minute. In the end, the event didn't happen. As conference organisers we attracted criticism for this, despite the fact that it wasn't our responsibility to organise. This needs to be organised by the board or someone from the OSGeo community, and needs to be planned well in advance. People look forward to it as an established part of FOSS4G.

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.

Target audience

It is strongly related to the objectives showed above. OSGeo has become more than a group of passionate, pioneer programmers, so the main OSGeo event should take into consideration the diversity of interests that are now part of it. The RfP should clearly state the target audience, so that the LOC can optimise organisation for it.

Voice

A conference like FOSS4G needs a voice, a style, a personality. Call it what you will. We felt that after missing a FOSS4G in 2012 it was important to project a loud and self confident voice to potential sponsors and delegates. Inevitably this voice did not work for everyone but overall the feedback was positive.

Message to future FOSS4G's - identify a voice and use it throughout your communications

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

Internal 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 and 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 accommodation

External communications

Web site

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

Twitter

We were given the password to the FOSS4G twitter account by the Denver team (now handed to Portland) and we used it extensively to communicate with delegates.

Several of the LOC had access to the account and that created a couple of slight glitches but generally it worked well. Making use of the twitter channel needs a fair amount of time and having a few people to share the load was helpful.

It was important that most messages to the twitter account were responded to within a couple of hours (often faster). We built up a dialogue with several of our followers.

It is important to remember that while twitter is an important and very effective channel for communicating with those who are engaged with twitter it cannot be the only channel to reach our audience. It is probably reasonable to expect the usage of twitter to increase in the future.

OSGeo mailing lists

The mailing lists are an important channel of communication. An LOC member was responsible for posting updates regularly to the lists (Discuss, Conference_Dev and FOSS4G2013) we endeavoured to respond to any queries or comments on the lists.

Press releases

The FOSS4G audience does not seem to be a press reading audience. This may reflect the changing ways that we receive information in the geo community.

We built up a press list of print and online media and issued about 10-12 press releases which got picked up by most of our targets but none of the media followed up with any interest in the event, requests for interviews or to attend the event. It is difficult to say whether this is because we were inexperienced at dealing with media or because there is a lack of interest on their part in open source geo.

We would have liked more media coverage of the event both in the build up to add delegates and sponsors and during/post event to generate some comment pieces highlighting the growth/strength of Open Source Geo. Perhaps future events should allocate some budget to press relations.

email to delegates

The conference chair sent a weekly mail to all registered delegates on a weekly basis for the last 10-12 weeks before the events. The mails were also posted in a delegate info section on the web site

Feedback on the frequency and style of communication was very positive.

Sending mail to 7/800 people requires a good mailing list and some mail software - we maintained a list derived from our registration system on google docs and used gmail for the large mailings.

email to sponsors

Through the build up to the conference the Chairman sent regular mail updates to sponsors covering both sponsor specific logistics and general info on the way the conference was developing.

Sponsors gave very positive feedback on the level of communication

what worked

The combination of the web site, twitter, mailing lists, press releases and direct mailings to sponsors and delegates worked in that very few people commented that "I didn't know ...."

Having team members dedicated to the different channels worked very well as it shared the load.

what would we have done differently

At times we may have inadvertently been less inclusive than we would have wanted to be (e.g. our frequent references to GeoBeer). Perhaps tasking someone with keeping a focus on inclusiveness in future would be an improvement

Venue

General

Our venue was part of the University of Nottingham. There were two distinct elements to the site: the East Midlands Conference Centre area, and venues on the rest of the University Park campus. Our point of contact for booking the venue, and then for making any arrangements on both parts of the site was the company De Vere who right at the start of the conference development process (after our proposal was selected) had taken over management of the conference facilities on behalf of the university. We were assigned an account manager who we worked with right through the conference - in addition we had good contact with the General Manager because of the size of the conference and some specific requirements. During the conference we had support from the operations team in the EMCC.

EMCC

De Vere had direct control of the EMCC area - this included the conference centre itself, the Orchard Hotel, and the immediate grounds (relevant because of we planned to use a marquee (tent)). For facilities on the rest of the campus, De Vere interfaced with the facilities teams of the university. In theory we therefore should have interacted with De Vere alone in making venue arrangements. We had a backchannel available in that Jeremy Morley is a lecturer at the university, and this was useful on occasion.

Right from the start (when we were putting the proposal together) we knew that the EMCC alone was only big enough for our absolutely minimum contingency number. The main lecture hall capacity was about 520, for example. We had looked at other possible locations. Our reasons for choosing the University of Nottingham were:

• availability of computer labs on-site
• low cost relative to stepping up to a single integrated conference centre
• previous experience with dealing with the site (albeit not at the conference centre)
• local team on site

The EMCC had 9 rooms available for presentation sessions:

• a lecture theatre. This could take 520 in a tiered seating configuration. The front rows of seats could be pushed back to make a flat space, e.g. for dinner events.
• a banqueting suite. This could hold ~800 as one big space or be divided into two roughly equal spaces
• four "stream rooms" of 120, 100, 100 and 80 capacity
• three meeting rooms on a upstairs gallery (10,25,30)

In addition there was an atrium bar where informal gatherings could be held. The main passageway had a bar too. The venue had the capability (at extra cost) of providing a video link (either one way or two way) between the lecture theatre and the banqueting suite.

We had an option to put a marquee on the back of the EMCC. There was enough ground area to use a marquee big enough to accommodate everyone up to our maximum projected capacity of 1000 people all at once.

We therefore had a number of configurations available - how we chose to use the space was related to our choices of social events in particular. We knew we needed to get everyone into a single space for the gala night event; we thought we could manage with a split room arrangements with video feed for the plenaries (once we had exceeded the lecture theatre capacity). We also needed a space for the sponsor stands.

We chose to use the EMCC as follows:

• the lecture theatre as the primary plenary space
• the four stream rooms for the presentation tracks
• the banqueting suite split in two halves through the whole conference with the sponsor stands in one half as well as a main food serving point. The other half would be used as the secondary plenary space (we decided to use a one-way video link as it was cheaper) and between plenaries as a fifth stream room in the building.
• keep the gallery rooms for side meetings & for use by the events team
• order the biggest marquee that would fit the ground area to be sure to be able to fit 1000 people.

We knew from the start that wifi was going to be critical for this conference. We particularly focused on communicating this to De Vere. See the section below for more discussion of the wifi.

University

As stated above, an advantage of using the university was the availability of PC labs. This meant that we didn't need to hire in PCs, and that some level of technical support was already on-site in the university's IT teams.

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

The conference was based in 2 main buildings, the EMCC and the Sir Clive Granger. We invested in wifi in the EMCC but relied on the university's "guest wifi" in the SCG (and the other buildings used for workshops) this was inadequate and prompted some complaints.

Advice to future FOSS4G organisers

Most venues do not have enough bandwidth or access points, consider paying for extra if you can

Programme (JM)

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-pollinate with industry, developers and users.

Merchandise and Branding

Firstly, like everything else, you have to judge the numbers for merchandise before you have the final numbers of attendees. You obviously want to have enough to go around, but you don't want to have too many left over at the end of the event!

Make sure that you know the lead-times for merchandise printing- these can vary from a few weeks to over a month. Get the items delivered to the venue if you can- but ensure that you get them correctly labelled so they don't get lost when they arrive.

Branding- it's a shame that this needs to be disposable- eg thrown away after each event. Consider recyclable or reusable options where possible.

what worked

• Make your own decisions about the types of merchandise to provide, but try to go for quality rather than disposable trash.

what didn't work

• We were too conservative about numbers so ran out of some items.

what would we do differently

• Ask for t-shirt sizes when people book, or you will need to ask later or guesstimate. It's not acceptable to just get men's shirts- get ladies shirt too and a range of sizes.

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.

Timeline:

• June - work started
• End June - First design concepts
• Mid July - Design sign-off
• End July - All editorial text to designer
• August - Lanyard Design work
• Mid August - All editorial content signed off
• End August - All adverts due in
• End August - Final proofing of booklet & Lanyard
• Very early Sept - All to printers

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, confirmation of programme held up the programme booklet
• 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..)

• More careful checking of source material before sending to designer - a glitch with the link to the online programme meant it all had to be imported a second time and incurred some additional design time

Workshops

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

Running the workshops at FOSS4G is hard mainly due to managing the technical aspects in addition to scheduling etc.

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 that they could take with them 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
• Lunch bags where popular with delegates and easy to administer

what didn't work

• Some delegates complained that the schedule did not provide a progression from intro to advanced
• Very poor feedback for those workshops that did not test material and suffered lost time and confusion
• Using heavily locked down university hardware made life a lot harder for organisers and presenters
  • Only one lab allowed VirtualBox, the others supported LiveUSB / LiveDVD only
  • The university HTTP proxy required additional set up
• People found the split between venues and navigating the university campus challenging due to the walking distance and directions
• Some complaints about unpaid delegates attending workshop
• Not all presenters signed up for the Conference Workshop list which meant that we resorted to mailing presenters directly

what would we do differently

• Look to schedule intro workshops before advanced if possible
• Publish the workshop schedule before selling workshop tickets
• Allow delegates to book individual workshops when they register
• Rent good spec laptops for workshops with a recent version of VirtualBox installed
• Contact presenters at least 3 months before the event to brief them on the facilities
  • You will need at least that much time to ensure that all presenters prepared
• Encourage all presenters to submit either a VM or USB/DVD prior to the event with instructions for testing
• Have each delegate checked off at each workshop to avoid unpaid delegates attending

Hackathon

The GeoHack hackathon ran in parallel to the conference workshops and was free to attend for registered delegates.

what worked

Twelve challenges were available, lead by different environmental organisations across the UK. Approximately 60 delegates attended and people worked on challenges in groups of 3-8 people. Despite being a free event (and therefore having less confidence that all registered delegates would turn up), we received the expected number of people which made the event run very smoothly.

Providing packed lunches on the day worked well and allowed people to eat when they wanted. Providing pizza and refreshment in the evening allowed everyone to stop and reflect.

The hackathon took place in the marquee, but despite being in a temporary structure there were no issues with electricity, wi-fi or the environment (heating/cooling).

what didn't work

To cover the costs of the free hackathon we worked with an external sponsor who helped to run the event and also put forward challenges around a single theme. Although this worked well it did remove some of the flexibility that would have allowed challenges and engagement from a much wider community.

what would we do differently

Ensure that people can register for free events using the same registration system as the main conference and workshops to avoid manual administration. There was a lot of duplication of effort, e.g. manually contacting all delegates individually to check that they were not simultaneously booked into workshops and asking again about dietary choices.

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 Beijing FOSS4G in 2012, and carried that over to the Nottingham 2013 conference. Our suggestion is to keep this effort going, and the ICA commission therefore are offering the Portland 2014 team its services to share experiences and coordinate the effort with the Portland LOC (it's our understandng 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 scientists have always been part of the audience of FOSS4G conferences, whether it be 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.

Software used: Open Journal Systems

For the FOSS4G2013 conference we used separate systems: WordPress and Django for the main conference site and the presentation and workshops tracks (see below) and OJS (Open Journal System) [1] for the Academic Track. All 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 proprietary and open source, and a suitable open source one seemed to be 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. In addition, Django was used for bespoke database functionality within the main site (e.g. managing registrations for workshops) that would have been difficult to implement in Wordpress.

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]. 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 appropriate outlet for the conference, as it is 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 came 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 year's 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 it 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).

Academic Bursaries

We received £5000 for academic bursaries from EDINA and we decided to open them up to Early-stage researchers who were defined as MSc/PhD and postdocs/lecturers in the first couple of years out of their PhD.

Academic Bursaries covered delegate fees and accommodation. This meant that we did not have to pass money to anyone. We also had the flexibility to transfer the award if recipients dropped out at the last minute.

Winners were asked to volunteer so it gave us extra help at the event.

Winners also wrote a short report on the event which was a nice way of disseminating information after the event.

Bursary info was distributed on OSGeo lists, academic mailing lists and by asking the academic track team to distribute on local lists in their country. It is hard to get the message out to international institutions but we had a good response from around the world.

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 in the "normal" programme worked well to generate attention for academic input in the community and to cross-pollinate 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).

Difficult to know if you reached all countries with messages about Call for Papers/Bursaries

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 journal's 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

During the conference we organised several entertainment events:

• Ice-Breaker : Delegates had to register separately for this event on the Wednesday evening. It revolved around a sit-down meal in the Auditorium. During the meal delegates were invited to create their own Robin Hood hats. Author and presenter Mike Parker was giving both a dinner talk and presenting a “pub-quiz” (created by LOC members) with a geographic theme and prizes. There were many delegates that remained until late, including quite a lot that did not attend the Icebreaker. The EMCC bar actually ran out of beer!

• Gala Night : The Thursday night party was included in the delegate registration. There was a Fork Buffet with four themed sections (English, Welsh, Scottish and Irish food) spread around the main conference areas. After that there were acts in the Geocamp: Steve and Helen from Festival of The Spoken Nerd, followed by local pianist Chris Conway and his band. Drinks were served from the EMCC bar.

• There was no "official" entertainment on Friday Night : We provided links to the bars and restaurants on the Nottingham Experience site. The EMCC bar and the Geocamp were open and used by a good amount of people. Late in the evening an informal viewing of the "Blues Brothers" movie attracted a fair amount of delegates in the Geocamp.

• Saturday Night’s Closing Party : This was a (registered) evening in the GeoCamp with speciality beer tasting, pizza and improv comedy.

what worked

The Icebreaker was successful, but there was a bit of confusion because it was not the typical icebreaker event that people might expect (a short drinks-only event for all without special registration).

The Gala night entertainment went down well. The Spoken Nerds were by most considered hilarious and very geeky and precisely right for this audience.

The various entertainment events obviously need logistics: The hardware (AV, PA, stage) were part of the deal with the marquee rental company. For tech support we were lucky to have a LOC member with roadie genes as well as a knowledgeable volunteer that helped out during the Gala Night.

what didn't work

The Gala Night Fork Buffet was appreciated but there was clearly a lack of enough places to sit down and eat it. The Geocamp could have served for this, but was rather far from many of the buffets and also there were not a lot of seats available there anyway.

Originally we organised a Friday Night Excursion to Nottingham Greyhound Track, people could have dinner and a race card in the restaurant box at the Nottingham Greyhound Stadium. For this event almost no delegates registered. This might have been because people were asked to phone the venue to register, or because dog-racing was not something FOSS4G-ers like? We quietly dropped it as an "official" event, but people could still attend.

The Saturday evening beer tasting was appreciated, but there was a lack of alternative (soft) drinks and the pizza was not very good value for money.

what would we do differently

Arrange for more seating places for dinner.

Volunteering

This is a big task and having a dedicated team member who can focus on this was important. The role of volunteer co-ordinator was an extra person brought in during June to manage this. Early on in the bid process, a call went out for people to pledge support for FOSS4G being in the UK. A number of people came forward to do this. The contact with these people between the bid process and June was limited. In July, a call for volunteers was sent out with a google form on the FOSS4G website to capture interest (sent to those who had initially pledged, as well as advertised more widely) more formally from those that would be able to volunteer in one of the following capacities:

• Paying delegates/ sponsors who offered time out of good will
• Academic bursaries - stipulation to provide half a day volunteering
• Free day passes - half a day volunteering for a free day pass to the event (with lunchtime catering)
• Recording/ video volunteers - organised by LocationTech

The call was echoed a number of times through the emails to delegates and sponsors running up to the event. The positive aspects of volunteering (ability to network, be part of the event etc) helped with interest levels.

They were also asked to indicate previous experience, interest in a number of tasks and days / number of hours they were prepared to assist. This was used to initially assign volunteers for a number of tasks, which included:

• Registration
• Session chairs
• Session assistants
• A selection of other random tasks

Most delegates were interested in helping with registration, but initially the focus was on having at least 1 chair per session, then starting to double up with assistants and other tasks. All volunteers were asked for preferences for sessions they were interested in chairing. An online google spreadsheet was used to indicate which sessions still needed assistance to provide guidance to those later in signing up.

In the last 6 weeks coming up to the event, a number of emails were sent specifically to volunteers to advise them on progress, where we still needed more help etc and to make them feel part of the volunteer team. A few questions came in and these were good to pick up before the event to make sure everyone was clear about what was expected or what to expect.

It was really important to ensure that there was a clear structure setting out expectations for volunteers and that the volunteer team felt supported in order to assist with the event and ensure that the time they were offering was valued. In the weeks running up to the event, the organising of the volunteers and programming of the tasks took a significant amount to time (daily emailing required to keep on top, co-ordination with all of the other tasks the LOC were involved in) - don't under estimate the scale of this task.

In advance of the event, all volunteers were inputted into the database system used for the programme. This allowed all presenters etc to see who was volunteering for specific sessions, but also to allow the team to look at the hours each volunteer had committed (there were some true heroes!). This also allowed a pack to be produced for each of the volunteers prior to the event (emailed) and also a physical pack including:

• Volunteer t-shirt
• List of assigned tasks (where to be and when)
• Briefing notes (on each of the tasks the volunteer had to perform and what was expected of them)
• Free beer token (provided by a sponsor)

As the number of tshirts was less than the general order mix, sizes for each volunteer were requested in advance and where provided they were labelled up for collection.

During the event, a conference office was the main point of call for volunteers and this is where packs were stored. Regular "opening hours" were advertised in advance so that there was someone there to answer questions and make sure all volunteers had let us know they had arrived at the event and picked up their pack. Each morning, a quick check of volunteers who were needed that day against those who had arrived at the event provided an early indication of any problems (but there weren't any!).

In terms of during the event, the first day was the busiest and required someone in the office for most of the morning/ until early afternoon to sort out the volunteers.

There should also be an awareness that there was a general lack of volunteers on the workshop days, as most of the delegates arriving for these wanted to attend workshop and not be volunteering. This should be considered in future as we could have done with some extra volunteer help during the early stages / early days.

We had around 60 volunteers in total and all of them performed as (or far beyond) there were asked to.

what worked

• organisation!
• asking volunteers for their preferences of tasks / sessions (many volunteers mentioned this as a positive)
• good communication
• spreadsheet with easy visual indications on the tasks we still needed volunteers for
• having a dedicated person to manage all this
• nicely organised packs for volunteers to pick up
• FOSS4G Hero Badges for those that gave an immense amount of time to the event, in addition to paying to attend as delegates

what didn't work

• having to spend the time before the event getting the volunteer details into the master programme database, it would have been better to do this as we went along
• a big gap between the pledges and then the volunteer call with little communication in between
• some confusion about LocationTech volunteers, this should just have been left to them to organise!

what would we do differently

See above re what didn't work... but mainly the volunteer feedback was excellent.

Timeline

The timeline from winning the bid to the event starting

During the event

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

what worked

Wifi strengthening gave delegates a high-quality connectivity, even given the QGIS 2.0 release announcement and subsequent download peak.

what didn't work

Last-minute workshop subscription was not especially effective, but in the bigger picture of workshop organization, it offered an extra possibility for the delegates to attend them.

The number of OSGEO Live DVDs available was not enough to provide all delegates with a copy, although in theory it shoudl hav been. So either make sure poeple don't take extra copies, or have enough extra copies...

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.