FOSS4G 2009 Lessons Learned

From OSGeo
Jump to navigation Jump to search

See also: FOSS4G2007_Lessons_Learned and FOSS4G2008_Lessons_Learned

Bidding

  • Find your local tourist bureau to help you bid. The Sydney Convention and Visitors Bureau helped us significantly, providing all the statistics and photos you need to promote your city. It is boiler plate stuff for them.
  • Plan ahead. FOSS4G moves around the world to give everyone a chance to attend locally.
    • Bidding cities should take a long term strategy. If you don't win one year, keep submitting until you do.
    • The bid committee should suggest regions they would like to move to in the near future which will encourage cities in that region to bid.
    • Feedback to unsuccessful bids should include targeted feedback, including rankings, to help cities refine their bid.
    • Cities should engage the local conference industry. They are likely to provide their services for free in order to secure the conference.
  • Network locally. A large, diverse team is attractive to selectors.
  • Be open in your bidding process. While it may allow competing cities to gain advantage, you will demonstrate your strength and openness to the OSGeo bid committee.
  • Talk up your city and local involvement at FOSS4G the previous year. Tim Bowden talked up Sydney's intention to bid for 2009 at FOSS4G 2007 and no other city decided to bid for that year.

Reference: International Conference delivered to your doorstep by Cameron Shorter

Commercial In Confidence Documentation:

  • Open Source developers often expect that all FOSS4G documentation will be Open. Unfortunately, the Professional Conference Organisor (PCO) industry seems to protect all their processes and documentation very closely. Consider this when dealing with them. Request up front for documentation to be made available publicly. Some documents, like Bid Proposals will probably remain Commercial In Confidence, and you need to ensure participants are aware of this.

Contract

  • Make sure that all documents created by the PCO (logos, sponsorship documents etc) are provided to you in source format. You will almost certainly want to update them later based on feedback, and you want don't want to have to pay a designer to make a simple tweak. We had a designer create a beautiful sponsorship prospectus (provided as pdf), but sometime simple and easy for us to change would have been cheaper and easier to change.

PCO Selection

  • Select your Professional Conference Organisor (PCO) earlier rather than later, preferably before you put your proposal in. The PCO should help you put your budget together, and if they put the budget together for the bid, they should be well advanced when you win.
  • Instead of using a PCO, consider using a non-profit organisation like GITA or SSI. These organisations often have expertise in organising spatial conferences, have contacts in the spatial industry, and are not out to make a profit from your conference. We naively expected our PCO to convert our potential sponsors list into sponsors, but almost all sponsors needed to be invited by a member of the Organising Committee.

Technically Savy

Our PCO required training to become familiar with Geek communication practices. In particular, the PCO preferred telephone conferences over email lists, wikis and IRC and was unfamiliar with email voting. This required training and negotiation with the PCO.

Lesson:

  • Ensure PCOs have realistic expectations regarding our communication habits up front by describing them in our PCO tender documents. In PCO selection, include familiarity with email lists, wikis as one of the selection criteria.

Conflicts of Interest

Our PCO offered provided many of the conference services in house. This provides a financial incentive for the PCO to upsell services (like a professionally produced Prospectus which we couldn't edit later without being charged extra), and being over charged for items - eg. We were charged for communication which included the use of email.

Lesson:

  • The PCO should not get to provide services for line items in the budget.

Decision making

  • Collaborative decision making is good, but make sure each committee has a chair-person with the mandate and authority to make decisions on behalf of the committee. (The chairperson should consult the committee and aggregate comments). This should make the committee significantly more effective.

Sponsorship

  • Make sure you have access to, and can edit the source format of the prospectus. We found we needed to pay our PCO every time we needed to tweak our prospectus, and FOSS4G has no shortage of competent geeks who can do most things.
  • Make sure you distinguish between the different sponsorship levels. If a sponsor pays more, then should get more. Development companies will likely want a keynote presentation slot.

One potential sponsor wrote: 

> We've been discussing sponsorships options, but can't really identify any significant
> advantages that justify the difference in price between the gold, silver and bronze
> sponsorships. Could one of you explain in more detail OUR benefits/advantages of
> chosing one of these options as opposed to an other, e.g. gold vs. silver or silver
> vs. bronze?
  • Possible Marketable benefits:
    • Guaranteed presentation slot (for Gold or above)
    • Plenary lightening talk (only if the company has something really useful to say)
    • First dibs on session chair slots (platinum get the plenary session chair slots). Sponsor can project their slide as people file in, and while doing their first introduction. Also get an opportunity to introduce yourself and your company, and maybe advertise a presentation you will be giving later.
    • Logo on website and in conference book (for all sponsors)
    • Access to list of attendees (without emails) to all delegates
    • Access to all delegates who tick "allow my email details to be shared with sponsors" box on registration form. Silver sponsor and above.
  • We used a password protected Google Docs speadsheet to manage the list of potential sponsors. This worked particularly well and I encourage others to do the same.

Venue booking & Conference dates

  • During proposal development, the bid team selected two venues for the conference:
    • The University of NSW
      • Pro: Has accademic ties
      • Pro: Has cheap university accommodation for 500 near by (share bathrooms)
      • Pro: 10 mins bus to beach
      • Pro: Cheaper, by ~ $50/delegate
      • Con: High end accommodation is 20 mins by bus (in city)
      • Con: Would need to bus delegates to the city harbour for an impressive dinner
    • Sydney Convention and Exhibition Center
      • Pro: Professional, classy center
      • Pro: Right on harbor, so easy to ship delegates to dinner location is style
      • Pro: Wide range of accommodation near by.
  • We postponed venue selection till after we won the bid, and consequently SCEC did not hold our preferred date for us.
  • Despite the initial analysis of the dates to be avoided (e.g. due to conflict with cultural or religious holidays, other conferences, etc.), As of early September 2008 we had still not booked a venue and it appeared that the Sydney Convention and Exhibition Center (SCEC) was only available on dates that overlapped with the USA thanksgiving weekend (which is in late November). We were able to salvage the situation by booking the SCEC for dates in October rather than November, however the availability was limited, and restricted our options.

ALBERT Kelly wrote: 

> Hey guys,
>
>     I know I've mentioned that the end of September is a killer time to get US Gov't
> people to come to a conference because their Funding year ends on 30 Sep.  So, thank you for not
> putting the conference on the last week of Sep!!!


Lessons:

  • Ensure that an early decision is made regarding the Venue, and the dates. If a venue can be booked for 'the entire week', the fine tuning of the actual days and rooms required can be done later, but being able to know 'the week' allows for marketing of the event, such as at the prior year's FOSS4G conference.
  • In terms of communication the critical nature of the date should have been better communicated by the Organising Committee to the PCO.
  • When considering cost/delegate, be mindful that international delegates will likely be paying thousands of dollars on travel, accommodation and lost income. $50 price difference in the conference will not effect them much. (It will effect local delegates more).
  • Pick a date that doesn't conflict with national holidays of key markets.
  • Find out when related national and international conferences are being held and make sure you don't clash. FOSS4G 2008 was on at the same time as Europe's biggest Geospatial fair, Intergeo. Here are this list of conferences we watched for 2009: FOSS4G_2009_Marketing_Plan#Related_Conferences.
  • Be aware that PCOs can reduce costs substantially by adjusting the number of rooms used, or using rooms off site for workshops or code sprints.

Facilities

OSGeo attendees want access to local facilities and these should be researched before hand, and details provided on the website.

For some things, like printing and CD burning, it helps to set up an account with a trusted local source (as was done for FOSS4G 2008). See FOSS4G_2008_Media_Facilities.

Attendees want:

  • CD/DVD printing
  • Paper printing (for workshops)
  • hire of general IT services, computers, projectors, etc.
  • An address to ship materials/equipment to ahead of time.

Website

Note that some of the issues related to the website for 2009 will likely not be an issue for 2010 and beyond, because the OSGeo Conference Committee will provide the 'basic infrastructure'(e.g. DNS setup, webserver setup) for the website to the local organizing committee for 2010 and beyond. Though, a decent conference system software needs to be chosen which supports on site management of sessions (like the free Indico which was successfully used for www.foss4g2006.org).

Lessons:

  • We have spent considerable time communicating/deciding the URL - if the format of the conference URL is not standard (i.e. http://20xx.foss4g/) then make a decision early.
  • If a PCO is being used and they are supplying the website then liaise as early as possible with their technical contact and set out expectations on what the site should be (and not be i.e. .ASP)
  • Provide whomever is doing the website with as much reference material as possible - if they are a PCO they will not know anything about FOSS4G therefore they are at an immediate disadvantage when it comes to creating content for the website

Budget

Get your budget agreed to before you sign a contract with the PCO. We found items in the budget, like accommodation for the local PCO attendees that caused us friction. It would have been better to have these sorted out before the contract was signed.

Marketing

Target money

  • Sponsors want to know that they will make money by sponsoring the conference. Source speakers from big spending programs to talk. These will attract delegates interested in those programs and sponsors who want to get work from these programs.
  • Feedback we got from sponsors was "We thought FOSS4G was just going to be a techie conference and wouldn't lead to sales". You need to push the Business side of FOSS4G too. Push Business Case Studies, Integration into Spatial Data Infrastructure, Spatial Government, etc.

Press Releases

Keep them concise. The more that is written, the less it is read. Our early press releases were too long and feedback was that people were not reading to the end of it. Keep the long winded explanation to the website.

Press release pipeline

On advise from 2007, as per FOSS4G2007_Lessons_Learned#Use_Proxies, we built up a press release pipeline, making heavy use of Community Leaders to forward the FOSS4G press release, with a paragraph or two introduction, to their communities. This

We built a spreadsheet of community leaders, including name, email address, and email list or publication they were a leader in. The list can be accessed by Cameron Shorter or Tyler Michel from here: http://spreadsheets.google.com/ccc?key=pu9014gybzrd1M6FqyOzGWg&hl=en_GB . Talk to either of them if you need access for future FOSS4G conferences.

  1. Lesson: Build this list early.
  2. Lesson: Ask community leaders to CC you on emails they send out, so that you get feedback on which communities are being reached, and whether you need to find a new leader for a particular area.
  3. Lesson: Select a schedule for press releases a publish it before hand. This helps magazines and Linked In owners to plan their releases to help you.
  4. Lesson: Don't send press releases just before a public holiday. We sent a release two days before Easter, and found many respondents were on leave. When they return, they will have a pile of email to attend to and your press release will likely be deleted.

Translations

We had community volunteers translate the website and press releases. The theory is that local translations will reach into local communities and demonstrates the international roots of the conference. Examples: http://2009.foss4g.org and http://wiki.osgeo.org/wiki/FOSS4G_2009_Press_Release_7_Translations . A list of translators is also available at: http://spreadsheets.google.com/ccc?key=pu9014gybzrd1M6FqyOzGWg&hl=en_GB

Tutorials

Workshops

  • Provide a range of options for user level (Beginner, Intermediate and Advanced) and category (User, Developer) and provide strict definitions of what these terms mean. Use examples.
  • Read previous FOSS4G2007_Lessons_Learned#Format_of_the_Call lessons learned so you don't have to learn all this yourself.
  • Having people fill out document templates and submit worked, but was a pain to juggle. A web form would be much easier, would eliminate some of the stylistic issues that I will need to sort out before getting things into the program and can enforce the word limits and the use of the correct template.
  • 100 words may be enough for a single instructor biography, but it's entirely insufficient when there are several. We had one submission that hit 500 for three instructors, and it would have been great to print that.
  • We put word limits on everything that would be published, and some things that wouldn't (such as Instructor Experience that was only used for assessment). We should have indicated explicitly what was for publication and what was strictly evaluation. No word limits need to be imposed on the evaluation only, but then you'll have to read it.
  • Having a separate submission path for tutorials than workshops allowed specific information to be captured for each. It likely cost us tutorial submissions where simply having a Workshop, Tutorial, Both selection would have made it trivial to submit both.
  • A number of people didn't realise there were templates for submitting workshop and tutorial details. The web form would solve this, and I don't really know how to make it clearer within the OCS system. Ideally a submission wouldn't be able to move further until a document was uploaded. Two submissions failed due to not submitting the doc.
  • Review the submissions early. I saved a couple of people by pointing out that the files they uploaded were not the correct templates, or they hadn't provided anything at all.
  • Review often too. In the final week, when most submissions arrived, I reviewed as soon as I received notice of a submission. Then I could get after them while they still had it on their minds.

There's a hard lesson I've learned, and I'm still not sure how it should be handled differently. We have a tradition of open selection of stuff. Workshops have always been less open, but we still involve community input. What I've found this year is that the only people offering this input were those with workshops or tutorials in. This means that the more people in your org that volunteer to review the higher your chance of getting in. To some extent this is fine. I think at worst we had three from one org, out of eleven, and one didn't complete his input. But in the end we lost some great presentations because they weren't there pushing for them. One in particular fit with the goals of the conference perfectly but wasn't selected because of the advanced content. Somebody else got their advanced content in instead, though I don't recall who. It was part of the recommendation to weight for beginner themes.

If I were to do this again, I think I might try the following. First, I wouldn't submit anything myself. I did have concerns over perceived conflict of interest, which was one big reason I pushed for the community selection. Second, I would refine the selection criteria much more than I did this year. Make sure it made it into the press release, was published on the wiki and on the submission form. I would then perform the selection myself. IIRC, the original reason for community involvement in the selection was not to be inclusive, warm and fuzzy, it's because it's a hell of a lot of work. Workshops are doable by a single person, especially once the selection criteria are explicit. Frankly, those that are interested in helping with this sort of work are generally not our target audience anyway. Presentations are different. They're closer to the event for one. We're more organised by then. And there's simply too many for one person, or even a small group, to handle in isolation with any kind of efficiency. I wouldn't expect this to go well with the community. It defies convention. In my case at least, simply not submitting my own workshop wouldn't really eliminate the spectre of conflict as others in my org had submissions in. I'm not completely convinced this is the correct solution, but it's what I've come up with.

Abstract Selection

  • The Abstract submission form supported only one presenter, but sometimes there's more than one presenter. Make it possible to submit detailed information about several authors.
  • It would have been useful to profile reviewers, so that we could weight reviewers against expected attendees. In particular, I would have liked to collect:
  1. Geographic Location.
  2. Sector: Development, Academic, Government, Utilities, Private, other
  3. Position: Developer, User, Manager, CIO, Decision Maker
  • It would have been useful to have a "Comments" field for reviewers to add comments as to why someone was or was not reviewed high/low.
  • In reviewing abstracts from our community, some abstracts received 40 votes for just their abstract. This may have been encouraged by our press release, which encouraged abstracts authors to get their friends to vote for their abstracts. http://wiki.osgeo.org/wiki/FOSS4G_2009_Press_Release_17. Lesson is that we should encourage people to promote the conference, but not stack the odds.

Recommendations to Abstract Authors

  • The following advice should be provided to abstract authors
    • Mention key themes of the conference and how your abstract is addressing them. Some 2009 abstracts did not mention Open Source or Open Standards.
    • Describing "vapour-ware", an idea that you would like to implement is not very compelling. Presentations should focus on specific technologies that already exist, or how you have used these technologies.
    • If presenting case studies, make sure you include "the positives and negatives encountered in your approach".
    • Be specific about what you will be talking about. "I will be talking about how Open Source can be deployed on Proprietary" is not enough for a reviewer to determine what will be talked about.

Tools

Google Analytics

We are successfully using google analytics to monitor the foss4g website traffic. Using the geographic breakup of the traffic we can understand which regions of the world require more aggressive marketing.

We created a generic gmail account for foss4g@gmail.com. This was done by Shoaib Burq and the password was shared with other committee members.

On 1st of March we had been using Google Analytics for about 2 weeks during which period only 2 hits to the site were from China.

We are looking to ramp up the Asian marketing.

Google Docs

Google docs proved to be quite successful for collaborative editing of documents and for creating draft conference time tables

Retrieved from "http://wiki.osgeo.org/w/index.php?title=FOSS4G_2009_Lessons_Learned&oldid=39723"