FOSS4G2013 Reflections by the LOC

This "FOSS4G 2013 Reflections" 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, programme

Jo Cook, Deputy Chair - web, liaison with OSGeo community, merchandise, ice-breaker

Jeremy Morley, Deputy Chair - liaison with university & De Vere, technical stuff for workshops, programme, gala night, liaison with AGI GeoCommunity

Abigail Page - programme book, co-ordination of volunteers (before and during the conference)

Addy Pope - educational bursaries, ice breaker

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

Barend Köbben - academic programme, cartography, programme

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

Claire Gilmour - organisation, organisation and organisation, registrations, liaison with AGI GeoCommunity

Franz-Josef Behr - academic programme

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

Ian Holt - workshops

Kenneth Field - Opening up the Map competition

Mark Iliffe - workshops, closing party, liaison with AGI GeoCommunity

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 and indeed it had been stressed to us that it was an important programme item to include.

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.

( There was of course another objective, to generate a substantial enough profit to fund OSGeo's activities for at least the year after the conference. Guaranteeing a good profit margin builds in a tension versus ticket price and hence being able to attract as broad a range of the community as possible. This can be offset by getting good levels of sponsorship (which is something we managed to achieve). )

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

It's important to remember that FOSS4G is a community event organised by the LOC on behalf of the wider community.

AGI GeoCommunity

A stated aim in the proposal was to run FOSS4G 2013 back-to-back with the AGI's own annual conference, GeoCommunity. This is a smaller (~500) conference, aimed principally at the GIS industry in all its guises in the UK. We particularly wanted to run these events back-to-back to help with the outreach & new community goals of FOSS4G, and to give GeoCom delegates an opportunity to stay on and find out more about OSGeo software and systems.

There is more about the relationship between the events in the #Venue section below.

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., but see comments above regarding the role of Board in setting such policies. 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. It seemed that the Board was conflicted between the "meeting of the tribes" with open, cheap access, and generating an operating profit for the organisation.

Registration Systems

Can someone extend this

We used - regonline - custom django code for workshop credits - eventbrite / excel for hackathon

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.

Basecamp supports a means to export an archive version as a simple website. At the time of writing this is still to be finally tested "in anger" to archive our discussions.

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 as well as tracking progress & meeting deadlines.

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 (April)

• Day long face to face focussing on logistics with the deVere team before the event started (July)

• Final day long face to face to write this wiki, approve accounts and debrief with OSGeo Board rep (November 2013, after the event)

Face to face meetings are more productive than conference calls but they incur cost for travel and over night accommodation, and either understanding bosses or time off work for the LOC volunteers.

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.

Lanyrd and EventBrite

We used these to help publicise the event, and in particular to organise bookings for the Hackathon prior to the main conference. We're not sure how much use these were for the main event though.

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 or ensure that they have a LOC member with strong experience in this aspect.

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 [1]. 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 with the company De Vere [2] 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.

In the deal with De Vere we were basically paying to use the EMCC, food per person, a contribution to a wifi upgrade. Part of the deal was also to "buy" rooms in the hotel. The use of additional rooms on the university campus (both PC labs and seminar rooms) was effectively free.

Because of the complexity of the event's requirements, the contract with De Vere was not signed until the start of the summer, shortly before the event. This was a risk for both parties, and a point of stress for the conference chair(!). However by then we had a good working relationship with De Vere and both parties could see that the issues were being closed off, one by one, and it would have been too big a loss on both sides to let the event fall through.

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 we planned to use a marquee (tent) at the back of the venue). 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)
• various accommodation (see below) right next to the EMCC
• 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 decided to have a heating system for the marquee (September is unpredictable for weather conditions in the UK) and were glad to have had it. We ordered an AV system (big projector plus amplifier & mixing desk), furniture and lighting system.

We knew from the start that wifi was going to be critical for this conference. We particularly focused on communicating this to De Vere early in the process & discussed a performance-related contract term. De Vere had the opportunity to improve the wifi on the EMCC site - there was effectively no influence that we could have over the wifi system on the university site. See the section below for more discussion of the wifi.

Catering for ~800 people is a challenge simply to get the food out and everyone moved past it to fill their plates. We had a deliberately "feathered" programme around lunchtime - four streams continued into the start of lunch & four started before the end of lunch. This meant that the whole lunch period was 1.5 hours long and there was a central 30 minutes where everyone was at lunch. This helped with smoothing out the catering demand. We also ensured that there were catering points in different locations around the EMCC (with De Vere's help). Lunch was only served in the EMCC (to get everyone together to enable networking) . The morning and afternoon breaks had catering in the Sir Clive Granger building on campus too to save time (so we didn't allow as much time for these breaks for transit - they were 30 minutes long).

We felt it was particularly important to give people a little longer to distribute after the first opening plenary as everyone would be concentrated in one or two rooms, would want refreshments, some would need to get to the Sir Clive Granger building, and most people would not yet be familiar with the locations.

The marquee was a multi-function space for us. We decided not to use it for the main programme (though the projector & screen meant it could have been used that way). It was used for the hackathon on the pre-conference days; as a quiet space for self-organised meetings during the conference; for the Thursday gala night, to project a film late on Friday, and for the closing party on the Saturday; and finally for the Sunday code sprint. We were concerned not to fill it with furniture so people couldn't see the acts on Thursday evening, but probably hadn't really appreciated the size fully (despite having used floor plans) and could have fitted in more furniture to give more seats for people to use when eating. All of this required that the marquee had good wifi coverage - we knew this from early on and part of working with De Vere on the wifi was that in their site upgrade they placed external routers on the building to cover the marquee.

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. The downside was that we would not be completely free to (re)configure the PCs - this is discussed further in the Workshops section. In this respect it greatly helped having a member of the university on the conference team as they could elicit support from the IT teams directly for some particular reconfiguration shortly before the event. We used 3 PC labs in one building from Tuesday to Saturday for paid-for and free workshops. We used one lab each in two other buildings for the two paid-for workshop days (Tuesday and Wednesday).

Some of the LOC had previous experience on running a FOSS-GIS conference on the site (the annual OSGIS conference).

Early on we booked a large number of seminar rooms around the university campus to give us flexibility of space (as this was free to us). We released rooms close to the event back to the university, but kept some rooms for possible additional meetings. We used one of the gallery rooms and two campus rooms for side events (groups wanted to do teleconference meetings; the Open Layers 3 code sprint; an OGC Board meeting). We also used a gallery room as an organising base for our volunteers.

For the additional streams we used rooms in a single building (the Sir Clive Granger building). This was approximately 10 minutes walk from the EMCC site. The reasons to choose this building were:

• three of the PC labs were located here anyway
• we had three available seminar rooms which fitted our requirements for additional stream rooms
• we had some familiarity with the location from the previous OSGIS conferences & from the local academics.

Accommodation

We offered two forms of accommodation as options in the registration system.

Firstly there was the Orchard Hotel, a good 3 star hotel on the EMCC site which had been opened less than a year before and so was well maintained. However the cost to delegates was relatively high. (The Orchard Hotel also fell into the De Vere wifi network). As part of the deal with the venue we reserved blocks of rooms in the hotel and were committed to pay for these blocks - in particular all the rooms on the Thursday and Friday nights. We released a number of rooms close to the event as it seemed that the hotel wouldn't sell out but we'd be responsible to pay for the unused rooms, but as it happened all the rooms did sell, but directly from the hotel.

The alternative was university halls of residence. These rooms were basic though at least en suite. Problems were reported either with cleanliness in at least some of the rooms, or with poor noise insulation between rooms.

Our accommodation included breakfast in the price.

Around a third of delegates did not use either form of accommodation but arranged their own in the Nottingham area. Our feeling was that it would be possible to find accommodation of a better quality at a similar price to the halls but it might not include breakfast; would imply additional travel costs to and from the EMCC; and that delegates would probably feel less a part of the social side of the event. However we respected this choice (and so did not force people to register in one or other on-site location) and clearly it was preferred by many.

AGI GeoCommunity

As discussed in the #Concept section above, we ran FOSS4G back-to-back with the AGI's GeoCommunity conference (which had a separate conference team but with cross-over members with the FOSS4G LOC). The venue booking was made so that GeoCom could run from an icebreaker on Monday evening to a closing plenary on Wednesday afternoon. In that time period, GeoCom had the use of the EMCC building. The FOSS4G workshops were in the Sir Clive Granger building and the hackathon in the marquee. FOSS4G registration was carried out in the marquee on Tuesday and Wednesday before transferring to the main desks in the EMCC for the main conference.

Marquee users needed access to toilet facilities. It was agreed between the two conference teams that a relaxed attitude would be taken to access to GeoCom - FOSS4G delegates from the hackathon could come into the EMCC through the link-way to the marquee to access the toilets, and none would mind if they lingered to find out more about GeoCom and its community. Nor would we mind GeoCom delegates coming down to find out more about FOSS4G and the hackathon particularly.

GeoCom hosts a party on its middle evening (Tuesday) that early arrivals for FOSS4G could buy tickets for, or come along to after the food had been served. This was particularly valuable for hackathon or workshop attendees.

what worked

• the arrangements for room bookings provided a great deal of flexibility for scaling the conference between 500 and 1000 delegates
• the marquee provided space for the Thursday evening gala event, our main "crunch time" of needing everyone in one space.
• the split plenary seemed to have worked. After the first two morning plenaries everyone could fit in the lecture theatre so we didn't need the video link throughout the whole conference (as expected and planned in)
• early contact with De Vere and having a local contact from the LOC helped make a great working relationship with them. This reflected back in the fact that De Vere created "tableau" on their own volition for each country-themed food serving point at the gala evening. They invested a great deal in a comprehensive wifi upgrade.
• from 5 months before we had semi-regular logistics meetings with De Vere. We also had a LOC face-to-face meeting on site 4 months before to have a day-by-day run-through of the use of the site and movements of people between sessions as an "idiot check" of the programme from a logistics point of view. This did result in changes in the programme and changes in the site use.
• the food was good in quality, though portions were sometimes a little small.
• we observed some cross-over between FOSS4G and GeoCom.

what didn't work

• the walk between the EMCC and the Sir Clive Granger Building was not ideal. The weather was mostly good which mitigated this. Being in one building would have been preferable but wasn't possible on our site (and we knew this from the start).
• we should probably have planned for more seating spaces, particularly for meals (and had room in the marquee to provide more). We had decided not to have so many places to avoid having to move furniture to make space for the gala night.
• as discussed below too, not having control over the university's wifi system (and its relatively locked down & sometimes unreliable state) made the experience in Sir Clive Granger less good, though the PC labs were all wired on Ethernet which mitigated some of the issues for the workshops.
• the EMCC had an unfortunate problem with waste water drainage (grey water) just at the start of the conference. De Vere worked quickly to mitigate this. It seems this was a problem that came to a head at the wrong moment after years of going unnoticed so in practice there's probably not much to say in terms of lessons learnt.
• generally the rooms in halls were acceptable to people as a trade-off in cost but the cleanliness issues (mostly poor cleaning in shower cubicles) in some rooms were a problem.

what would we do differently

• ideally a single venue would be good to reduce transit time, but wasn't an option for our site.
• more furniture, particularly places to sit to eat, around the EMCC would have been better. In particular, more tables & chairs in the marquee would have been fine.
• cleanliness of accommodation is critical and needs to be stressed if you're recommending possibly lower quality accommodation as part of your mix! Basic and clean is fine; basic and dirty is not.
• note that our venue at least was in part generating its operating profit on our event by selling hotel rooms and so were less pleased when we wanted to release hotel rooms before the event (though the venue did let us off the hook and the hotel eventually sold out for the two main nights, Thursday and Friday). Be careful with cost commitments that are difficult to undo later.
• contract negotiation: it all worked out well for us. However be aware that at the beginning the conference has the balance of power as the venue wants to win the business. We never had to face this but effectively the venue begins to have more power as the event approaches (if there's no contract) as the LOC can't conceivably take the conference to another venue after a certain point.

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. De Vere invested substantially more than this in an upgrade of the site, bringing in an extra fibre line & upgrading the wifi routers to ones capable of hundreds of people accessing each. They also installed weatherproof access points on the outside of the building to cover the marquee.

As discussed above under Venue, we had two wifi zones - the EMCC site, managed by De Vere, and the university campus site, managed by the university as part of its general provision and over which we had little control. The university supplied access to a guest network and the academic Eduroam network. The PC lab machines all had wired Ethernet connections on the university network.

The university networks (wired or wifi) were all mediated by a proxy and generally had TCP/IP port restrictions.

what worked

• Just about everything worked on the EMCC site, except for 1 router on day 1 which gave some users a problem, and some possibly related issues for Android users not getting redirected properly to the sign-in page. Having a dedicated technician on site for the first day helped to solve the problem and gave us a lot of reassurance. After the first morning of the main conference these issues seemed to have mostly gone away.
• For workshop organisers who engaged with our emails relating to network restrictions in the Sir Clive Granger building, we generally managed workarounds or simply to configure proxy settings on the day before the workshops.

what didn't work

• an unrestricted Internet connnection for the workshop computers would solve many of the connectivity issues (mainly proxy) that affected demos and hands-on sessions on the university campus.

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" or the wired connections 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, so consider paying for extra if you can and start early in working with the venue! It can take a lot of planning simply to upgrade the access at the site, even after convincing the venue of the requirements. Be aware that conference venues may be used to large events, but may not realise that "tech-events" have a much larger bandwidth requirement per delegate than other conferences. Delegates are likely to have more than one device, may require non-default ports to be opened (for committing code and so on) and may wish to download large files such as new software during the event. You may need to work quite hard to convince the conference venue of your requirements, but success or failure with connectivity can make or break an event. In our case we went in early with De Vere by suggesting a penalty clause in the contract in the case of wifi underperformance on the EMCC site and an action plan to agree the provision - we didn't include the clause in the end because of the great response by their team in providing a substantial upgrade and support, and indeed we paid a relatively token amount towards the upgrade.

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

Papers

Call for Papers

We used Survey Monkey to gather abstracts and presenter details. This worked pretty well.

With hindsight we should have set word limits on long and short abstracts to make it easier to include in online and printed program guides.

Paper Selection

We held a 2 day face to face meeting for paper selection, this was also an important part of our team building as we had limited face to face time.

Before the paper selection process, team members received an anonymised summary of all submissions from which they selected their personal top 100. These were then aggregated into a single LOC Top 100 (which required a common marking scheme - we thought of this a bit too late)

Stage 1: Selection

Cut 1: Community. Select c 110 based on community rankings. Review those with big disparity with LOC rankings, highlight any candidates for replacement, if low LOC ranking and not strong community ranking (c. 10?)

Cut 2: LOC. Select a further c. 60 based on LOC rankings. Review those with big disparity with community rankings, highlight any candidates for replacement, if low community ranking and not strong LOC ranking (c. 10?)

Cut 3: Community. Review remainder in community ranking order. Highlight any candidates for inclusion based on high community ranking. (c. 10?)

Cut 4: Review duplicate organisations - limit numbers if over-represented or overlapping, taking into account scope of company and likely level of interest. Candidates for replacement (if any) taken out where appropriate. If overlapping, ask company to consider merging or choosing from a pair of papers.

Cut 5: Review duplicate authors (including single author with multiple organisation) - no more than 2 or max 3 per author. Limit number if over-represented or overlapping. If overlapping, ask company to consider merging or choosing from a pair of papers.

Result: 173 papers, down to 169 when merge/choose requests are taken into account.

Stage 2: Classification Add up to four tags per paper, based on extendible list. Tags should reflect delegate profiles (eg developer, user, newbie, business).

We used a google spreadsheet to collaboratively tag the papers selected

Stage 3: Late submissions Consider and include any strong candidates in programme or on reserve list.

Stage 4: Applause and coffee

Stage 5: Contact authors Accepted/rejected: let them know Reserves: let them know, and ask them to let us know if they don't want to be on list.

Stage 6: Streaming (to be done) Using the tags, derive streams/themes, balance and rebalance programme. Publish classified programme on website (format to be decided, not necessarily yet in final programme format, ie with days and timings).

Stage 7: Programme (to be done) Finalise programme, with streams, themes, slots.

keynotes

We started the recruitment of keynote speakers very early on. We wanted to use the initial keynote announcements as a handle for early promotions.

In line with our aspiration to reach our target audiences (contributors, users and academics) we wanted to have keynoters who would interest each of these groups.

We brainstormed a long list of names and then a first cut list of targets to approach, with some stand-ins in the expectation that not all of our first choices would accept our invitations. We were inevitably limited by personal connections as to who we could reach.

A small part of the feedback was critical of the choice of keynote speakers and/or their content

streams

Note that we did not include a separate "Academic" Track or stream (see also section on the 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.

what worked

Good feedback on the program generally.

Balancing community voting with LOC views and creating a good conference program is difficult (the community of past attendees represents an important part of the audience but not the whole audience). Ultimately the LOC has to take responsibility for its judgement.

what didn't work

Scheduling is a nightmare when there are 200 sessions across 3 days! It is almost impossible to create streams, balance room sizes, popularity of speakers and factor in time to get from one building to another. We made a few mistakes.

what would we do differently

Allow some more time between sessions to enable people to move between rooms or buildings

Allow a bit of slack in the program to allow for over-runs

Allowing slack etc will imply reducing the number of presentations

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

We open-sourced the ideation of the brand rather than pay a design company. We ran a competition for brand ideas, then opened a community vote to select the best idea.

It's a shame that this needs to be disposable- eg thrown away after each event. Consider recyclable or reusable options where possible. However if your brand uses thematic elements for the location or time of your conference this may be unfeasible.

what worked

• An open call for brand ideas worked very well for us - we got a good set of ideas to choose from and a community vote worked effectively to give us the basic concept which we adopted and adapted.
• 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
• A printable version of the programme would have been nice to have (a few pages with the schedule, with title/presenter for each presentation and workshop)

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
• Have names printed on both sides of the lanyards
• Let some free space on the lanyards close to names, where attendees can write few keywords (interests, preferred software projects...)

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 much harder than you expect 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 were 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
• Finalise and publish the workshop schedule before selling workshop tickets
• Allow delegates to book individual workshops when they register
• Source good spec machines for workshops with a recent version of VirtualBox installed (this might mean renting laptops, for example).
• (as mentioned in Wifi section) request unlimited connectivity
• 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 have prepared, and some will arrive having not prepared, regardless of what you do
• 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) [3] 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. Details of academic track talks were exported into the conference programme database for integration into the web page timetable system along with the main track presentations.

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 -- see "what didn't work").

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.

The publication in the OSGeo Journal did/does not go very smoothly. That was in first instance our fault, as we did not make detailed agreements with the Journal team (as we did do with the TGIS editors). We were under the assumption this was not necessary because the Journal is part of OSGEO and has been the outlet for proceedings in the past. But it turned out that was under the previous editor, and the current team had no experience with this. By 15 May all selected 14 papers were uploaded (to http://svn.osgeo.org/osgeo/journal/volume_13/Raw/); But by November the editors had not moved forward on the issue. The editor-in-chief (Landon Blake) is very difficult to get hold of, and we finally have been in contact with Eli Adam (who is also on the FOSS4G Portland LOC). To move forward publication I have resorted to offer to do the LaTeX editing. Now busy with that and hoping to have the special issue on-line by Q1 2014.

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

Barry. Our web dev guru. Couldn't have done it without him. We definitely "in-sourced" professional level skills.

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 by those who attended, 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.
• Clarify beforehand (ideally in RfP) whether events shall be included in the conference fee.

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 month by month

-3 (July)

• face-to-face meeting in Nottingham based at the Orchard Hotel on the EMCC site, with De Vere representative in attendance. Focused particularly on the logistics of the event, to decide, for example, on the structure of entertainments & breaks, where to set up catering points, how to fit sponsor stands into the EMCC, and the use of rooms for streams. Important for "idiot checking" some of our programme ideas in terms of getting delegates fed & to the right places.

Wk -1

A lot of hassle regarding the workshops. A number of workshop presenters seemed to have finally focussed on having to deliver workshops having developed their content in ways that were contrary to the information we supplied on what our site would support. This meant a lot of time spent with the university IT people to work out what software updates could or couldn't be pushed out to different PC labs. The university was naturally cautious because they didn't want to destabilise their systems. Having good on-site contacts with the IT teams was critical here as De Vere's connection to the university didn't reach deeply enough into the technical teams. However for those organisers that did engage this way we found working solutions (albeit that it meant that one workshop, on PostGIS 3D, ended up in a smaller lab which was able to support VirtualBox but as a result suffered from overcrowding).

Less important for lessons learnt, but we also discovered that as part of a rolling schedule of building upgrade works, a pair of PC labs we were planning to use in the Sir Clive Granger building had been scheduled to have its windows removed & new ones fitted on the Friday (second day) of the main conference. In this case it was De Vere's connections to the university's estates group that managed to get this rescheduled.

During the event

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

On the day before the workshops (i.e. the Monday) we arranged troubleshooting sessions to test the workshops in the different PC labs.

what worked

• Wifi strengthening gave delegates a high-quality connectivity, even given the QGIS 2.0 release announcement (and the iOS 7 release) and subsequent download peak.
• For the workshop organisers that took this opportunity it proved invaluable in getting set up for the university proxy system & other site restrictions. Even with a less restricted PC environment we would highly encourage you to hold these test sessions in advance.

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 should have been. So either make sure people don't take extra copies, or have 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.

Sponsorship

We attracted a large number of sponsors, mainly due to the phenomal work that our Chairman did in the run-up to the event.

What worked

We had a "supporter" level of sponsorship, which was pitched at a lower level. This allowed companies a free pass to the event, and a mention on the website, but no exhibitors stand. This was popular, and while it might not have made much money but allowed smaller companies to contribute in a way they might otherwise have not been able to.

Parting thoughts

Experiences of sizes of conference

Some of the LOC had had experience of working on conferences of ~100 and ~500 people - these two are different scales of event. 500 is a step-change up from 100 people. For reference, we found FOSS4G (as we expected beforehand) was a definite further step up (from 500 to ~800). Partly this was because of the more complex event requirements (e.g. around the workshops) but partly it's simply to do with the greater numbers. This might be different if using a professional conference management company to buffer some of the activity.