FOSS4G Manual

From OSGeo Wiki

Jump to: navigation, search

Placeholder for future notes, lists, workflow for maintaining continuity between FOSS4G events.

Contents

Timing and Scheduling

  1. Request for hosting proposals
    1. Made public - early in the year prior
    2. Letter of intent submitted
    3. First stage selection
    4. Full proposal submitted
  1. Event dates ..

Lessons Learned - Past Events

To learn from others is wiser than suffering through it yourself. Here is a collection of Lessons Learned pages, put together by previous event organisers.

FOSS4G 2011

FOSS4G 2011 Home

Previous Years Lessons Learned

FOSS4G 2011 Lessons Learned

Starting this page early so we can document lessons learned as we go along where appropriate, for the benefit of future FOSS4Gs!!

We had a few misunderstandings over the logo requirements initially! This is a summary of requirements for the logo:

  • It must incorporate the FOSS4G "ribbon" element, which has been used in the logo of all FOSS4G conferences. Past logos can be seen here.
  • It does not need to incorporate the OSGeo logo.

The logo is something on which everyone has an opinion (often a strong one!). We recommend assigning a small group to get the logo done rather than having extensive debate with the whole team! We ended up using crowdspring and were very pleased with the way that this worked - we would highly recommend using them in future. Start on the logo asap as you need it for other early stage documents like the sponsorship prospectus.

Sponsorship

Make sure that your sponsorship benefits are a reasonable match for the previous year's, unless you have a compelling reason to change that you are willing to defend. In our first brochure we inadvertently reduced the number of conference passes provided, and quickly heard negative feedback about this from several people (in particular the fact that the bronze sponsorship included no passes rather than one). We changed the benefits to match the previous year in the light of this feedback. Also I suggest keeping sponsorship payment amounts somewhat similar to the previous year. In particular we had feedback that there should be an affordable lower level sponsorship as lots of small companies traditionally sign up for that.

We offered a 10% discount for sponsors who signed up early (by end of January for us), and this worked very well. I'd need to check but from memory, I think we had roughly 2/3 of our overall sponsorship money in by end of January, which was great.

We specifically decided that we would not offer keynote talks as part of any level sponsorship packages. We felt it's an important part of the FOSS4G ethos to not be "too commercial" and for the committee to have control over the content of keynotes. We did offer a guaranteed talk in a regular session (in parallel streams) for the top level sponsorship.

LOC Organization

The Chair needs to get assignments made to members of the team as early as possible, and delegate effectively. I (Peter) didn't do this soon enough.

Discounts

Have discounts/comps for workshops and tutorials clearly ironed out before making any call for proposals for workshops/tutorials. This affects who and how many presenters might submit proposals and what they hopes/expectations might be. This year, our budget only stated how many free passes, generally, were available - not with a particular number set aside for workshops.

Abstract Submissions

  • We allowed users to enter their name (including title) in a single box. This proved to be difficult to parse into firstname, lastname, title in order to check for multiple abstract submissions. Suggestion: have separate entries for firstname, lastname, title
  • We allowed users to check multiple boxes for type of presentation (i.e. lightning, general session, etc) from which it was impossible to determine if the submitter had a format preference. Suggestion: have users select choices from a "first preference (required)" and "second preference (optional)" pick list.
  • We mixed academic and general track submissions, which made the resulting datasets more difficult to process. Suggestion: Require submissions to be for either the academic OR the general track. Not both.
  • Suggestion: Allow users to supply a list of keywords (such as software package, application, etc) This would help to facilitate grouping of talks when scheduling.
  • Suggestion: assign an unique "abstract ID" to each abstract when it is submitted, and use it throughout the abstract voting process.
  • Suggestion: State explicitly the maximum number of talks (2) on the abstract submission form.

Paper selection

With the size that FOSS4G has now reached, this is a LOT of effort, even with the community ranking system (which is a big help). Work out the "shape" of the program ahead of abstract submission closing - how many tracks you have, how many plenary sessions and how long they run, how much space for the academic track and tutorials, etc. You need to know all these things in order to know how many papers to select. Check for multiple paper submissions from the same person relatively early if possible and decide how to handle these situations. We decided that we would be open to multiple papers from the same person, but in general a maximum of two (maybe in exceptional circumstances three). We had a couple of people who submitted 5 presentations. One strategy we used was to ask the person to combine multiple presentations where this made sense (e.g. they had multiple abstracts on similar topics). Another was to see if some presentations could be given by someone else.

Events that need to be scheduled

There are several items that need to be included in the program in addition to the general presentations. We found out about some of these late in the day and it would have been easier to schedule them if we'd known about them up front. These include the following:

  • Birds of a Feather (BOF) meetings - need about an hour and a half with availability of multiple rooms for groups to self-organize.
  • OSGeo AGM - not strictly part of FOSS4G, but a meeting that normally happens during the conference. Also plan an hour and a half for this.
  • The closing session needs to include the Sol Katz award (10 mins), next year FOSS4G introduction (10 mins).
  • Web Mapping shootout - not strictly mandatory, but has been an ongoing and popular plenary session. This has traditionally been in the closing session but doesn't necessarily have to be. Need to allow 30-45 minutes for this (talk to whoever is organizing it).

FOSS4G 2010

back to FOSS4G 2010

communication inside the organization

every LOC is different and it's not easy to establish the connection between OSGeo Board, the Conf Com and the LOC. It's curious how, even if we all want to help each others, it's so easy to get into misunderstandings. The Chair has a key role to make this process smoother and bridge between these groups.

suggestion: don't sub-estimate the difficulties that can arise from the LOC and the OSGeo communities. Keep supporting an open minded approach.

Registration

Simplify process.

Attendee Survey

  • embed in the registration proces
  • add:
    • Have you been to FOSS4G before (to measure how well we are doing

pulling in new people, since education is such an important foss4g goal)

    • Do you use open source geospatial software currently? (to see

whether people are coming for skills upgrading or basic introduction of a what-is-this-stuff sort)


web platform

when to start

Now! 

Get ready with your website so we can link to your site while many visitors are still on ours.

Create banners, logos, etc. of the same size and format so that folks who link to us simply have to exchange a file. We have conquered quite a bit of web space on others sites by now and should maintain this.


public website

The home page of the conference and all the contents to show to the public can be easily made in pure HTML (little php can help). Check other events websites.

abstracts platform

this can be the real PITA. As far we've seen there's not yet a good open source platform for this and the one from our conference company is nice to see but not even sufficient in terms of bugs, usability, features.

So double check your opportunities, you can avoid recursive heart attacks.

Academic track submission

  • definitely also collect keywords

Sponsors

  • don't wait for sponsors knocking at your door.
  • avoid mass e-mailing to potential sponsors.
  • prepare one-to-one e-mails to justify their involvement and offer support even to download a manual that's so easy to do. Let them feel comfortable.

abstract selection

  • We have received way more abstracts that what expected. 360 for 120 places.
  • coupling the selection of the Academic Committee and the Community Review is a tough job. We where 4 people during a long day together and we had to review our choices for the three days after from home.
  • Using a Google Spreadsheet has been really a good help. The chat included helps to let the LOC group to refine the selection but I would not use it instead of a face to face meeting.
  • suggestions: after the first selection, it's a good practice to leave 3-4 slots free to give the time to the community to react and help you choosing from the discarded presentations. There's always a good presentation that the LOC can miss and that can be added in a second moment.

media and communications

Start the media agreements ASAP, we've been little lazy with it. We decided not to spend money or free entrances with Media Partners and the time will tell if we did right. Anyway relations with media are important and we dedicated a person to it, choose one soon; he should take care of magazines and mailing lists for you. We hope to give a good list of international magazines and you will have just to extend the agreements.

Lessons at the Venue

Put a short bio of the speakers in the webpage with the abstract, hand them out to the session chairmans.

It would be a really nice thing to provide a backchannel from twitter in different places of the venue there is a whole paralel meeting there!


WIFI - that's always a problem. We couldn't do better. We reserved 500 connection but we had 500 passwords instead. So switching from one session to another would take too long even if the first computer was shut down. The lesson is: if you have to limit the total amount of connection be sure you receive something that can be easily switched from one computer/mobile to another so you grant you have always a maximum amount of connection active. Most of the people use the connection for few minutes a day and can share it with the neighbour.

Lessons at the workshops

Double check that your presenters are coming for sure. Even better if they provide a second presenter or alternate presenter (backup?!?). This should avoid what happened in Barcelona with the QGIS workshops that had no presenter and we had to move people and possibly refund them (40 people!).

T-shirts

selling VS gifting

We are still convinced of the idea of selling the t-shirts. The price is symbolic, there was no profit, we didn't want people to throw the t-shirt to the first dustbin just because it was an unwanted gift.

We've chosen to print a number close to the half of the supposed attendance.

sizes

We did a mistake over the proportions. Expecting european sizes we decided about the proportion of 1-1-2-1 with the size M-L-XL-XXL. Unfortunately the provider had international US sizes (Fruit of...) and we had problems to place most of the XL and XXL, while M and L where quickly sold out. For the next conference I would suggest a proportion of 3-4-3-1, should better fit the attendance.



Academic track

  • Communicate carefully the list of considered journals including publishing costs (if apply) to the community
  • Don't forget to have the Full-Paper Academic Track Proceedings on the Conference DVD.

Register an ISBN No. for the Full-Paper Academic Track Proceedings.

add other lesson

...

Related Discussions

FOSS4G 2009

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. Our doc was at: http://spreadsheets.google.com/ccc?key=0Al9zh8DjmU_RcHU5MDE0Z3lienJjZnpFU05lLW9rUWc&hl=en_GB (Talk to Cameron Shorter if you want access to it).
  • As host/funder/coordinator of the event, treat OSGeo similar to a primary sponsor - due to all rights, privileges and opportunities that other sponsors receive. This does not mean calling OSGeo a sponsor, but remembering to make sure logos are well represented and that booth space, keynotes, and other promotional benefits are included. Liaison with OSGeo Marketing or directly with Tyler or the Board.

Contra deals

We set up contra deals with the Australian Computer Society (ACS) and the Spatial Sciences Institute (SSI), offering a 5% discount and Professional Training points with ACS/SSI to members and ACS/SSI got to share a stand at the conference. In return we received a mention in ACS/SSI email blasts. Afterwards, we hardly got any members make use of this discount. I can guess at the reasons for this:

  • For the ACS, I don't think anyone asked for a discount. The ACS did mention the FOSS4G conference in their communicaiton, but I have my doubts that it attracted any delegates. The ACS was probably not a targeted enough audience, and our conference mention was only a few lines mixed in a mass of material, making it an email blast which doesn't get read by most people.
  • There were maybe 3 SSI members who claimed the SSI discount, and I think all these people were actively involved in the organising of the conference to some extent, and heard about the discount that way.
  • For the SSI, I did see a number of people at the conference who I knew were members of SSI, who had not taken advantage of the 5% discount. It is quite likely they heard about the conference through a SSI press release, but when they went to register (months later) they had forgotten about the discount. Of note, we didn't have a section on the registration website explaining how to use the 5% discount, people would have need to have remembered from the original SSI/ACS email blast.
  • Also of note, the SSI was going through management upheaval while we were dealing with them, with 3 people rotating through the Chief Executive role in the 6 months we were dealing with them. Consequently SSI as an organisation was not running at 100%.

Recommendations:

  • Continue making prudent use of contra deals with targeted organisations. Providing a 5% discount for members provides a cheap marketing technique and will only be used if the marketing works.
  • Ensure that marketing is bigger than a one liner in a list of other conferences. You are looking for a feature article in a newsletter about "GeoSpatial Open Source and FOSS4G" or similar. Also banner add on website would be good.
  • Where possible, tie conference benefits (especially ones that cost the conference like a stand) to the contra deal sponsor. Ie, if the sponsor is able to attract X delegates, they will get a free stand at the conference.
  • Try to collect better metrics about the success of contra deals for use with future conferences.

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.
  • Some venues may have higher public liability insurance requirements than others - this will affect exhibitors requiring insurance and potentially require a substantial increase in exhibitors costs if they do not already have massive coverage (e.g. one quote in 2009 was for around $700 for the 4 day show) and increases the barrier for attracting exhibitors. It was also a bit of a surprise for at least one exhibitor - and should be clear up front or at least as a warning.
    • 2009 event exhibitors, at the SCEC venue, required proof of $10 million public liability coverage to be allowed to exhibit. A 3rd party company was referred to for exhibitors that needed help but a tighter relationship would have helped earlier on, especially since many exhibitors are 'small'. (Tyler looked into getting coverage from several Canadian brokers and was unable to do so for that high of coverage.)

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.

Internet

  • Internet was one of our success stories, and one that we were worried about after hearing lessons from the last two years where delegates overloaded the wireless internet.
  • AARNET, the internet provider for Australian Academic institutions provided very fat internet pipe into the Conference Centre for free (as we were an Open Source conference).
  • Steve Walsh, a Systems Administrator who also helps set up Linux Australia conferences set up the internet for us and negotiated getting the internet into both the Conference Centre and UTS for the code sprint.
  • We had a number of comments from delegates who were very impressed with the speed of the network.
  • Steve: Can you please fill in some of the technical details here.

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

  1. 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.
  2. Similar to above, make room to discuss/identify OSGeo administrative requirements early on. E.g. free booth space, how many full conference passes needed for OSGeo, and special venue requirements (eg meeting rooms). Few allowances were made in 2009 budget to accommodate the hosts needs (needs were not identified by OSGeo either until too late).

Economic Climate

  • We won the FOSS4G 2009 conference in a financial boom, then had to run the conference in a bust, after the Global Financial Crisis. Consequently we were faced with many of our sponsors reducing or cutting sponsorship (Eg: Google moved from Gold to Silver sponsor), and many potential attendees had to face travel spending cuts and couldn't make the conference.
    • Lesson: Don't be the bunny who has to run the conference in the same year as a Global Financial Crisis.
  • Australia holds a large bi-annual spatial conference which attracts many of the government spatial delegates who would likely also wish to attend FOSS4G. The Surveying & Spatial Sciences Institute Biennial International Conference ran 1 month before FOSS4G, and we found that a number of potential delegates only had sufficient funding to attend one of the conferences. It would have made sense to pick the alternative year to this conference. This conference
  • The WALIS Geospatial conference, held in Western Australia a month after FOSS4G also had reduced registrations, down from 830 registrations in 2008 to 650 registrations in 2009.
  • The one Australian conference winner was the Spatial@Gov conference which started for the first time in 2009, 4 months before foss4g, and attracted 463 people. This conference would have attracted a number of people from foss4g, as it had a very strong focus on OGC standards, and also had ~ 1/3 of the presentations mentioning Open Source. The Spatial@Gov conference was deliberately started in competition to the Spatially Enabled Government conference which was privately run and seen to be very expensive in comparison. As expected, the Spatially Enabled Government conference had significantly less attendees than previously, and decided not to exhibit in Australia in 2010.
  • Overall, there was an oversupply of Australian Geospatial Conferences, and combined with the Global Financial Crisis, the conference organisors were faced with reduced profits or losses. FOSS4G 2009 did well to maintain a slim profit. (A few days before the conference it looked like FOSS4G would be making a loss as well).
    • Lesson: The Australian conference organisors (from FOSS4G, WALIS, Spatial@Gov, SSSI, CRCSI) have agreed in principle to work collaboratively to avoid oversupplying the Australian market with conferences. In particular, their is an aim to avoid covering the same material in multiple conferences, thus splitting sponsorship dollars and attendees.

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

See our press releases at: FOSS4G_2009_Press_Releases, also FOSS4G_2009_Press_Release_Process.

Keep press releases 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. Reason for using community leaders is that emails are much more likely to be read if it comes from someone you know and trust. This proved to be very effective, with Google Analytics showing that referals to our website came from a very large area from community leaders.

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. Assign someone to follow up to determine if the emails are going out.
  3. Lesson: Ask community leaders to add a personal message (see example cover emails from the Press Releases).
  4. 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.
  5. 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.

Cameron sent most of the press releases from his personal email address. Afterwards, he found that he had been included in some people's junk email filters.

  1. Lesson: set up a separate email address for foss4g related bulk emails

Email Lists

We obtained a spam list of foss4g potential delegates from previous events, which we added to with a number of local lists we found. This was copied into foss4g-2009-announce email list. In retrospect, we should have had two lists, one spam list for potential delegates that you only want to hit with major announcements to encourage the people to register. And then a second announcement list that people self subscribe to which you can email more regularly with gossip, buzz, and ideas for how people can further get involved in foss4g.

We also had: foss4g-2009-private, for discussing sensitive (financial) matters amongst the organising committee, and foss4g-2009 for all other organisational stuff.

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

  • See http://wiki.osgeo.org/wiki/FOSS4G2008_Lessons_Learned#Laptop_Based_Workshops
  • Many tutorials were overbooked, with people spilling out the door outside the room. (I wonder whether this was because tutorials were free, but contained much of the same content as workshops).
  • We had water jugs and glasses on the table. With a crowded room, people were nervous taking their computers out when there is water on the desk.
  • One of the tutorials was run from a Virtual Machine. Unfortunately, 1/3 of the computers in the room didn't have enough RAM to run the virtual machine.

Workshops

Submissions

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

Setup

  • Get lists of software needed by presenters early. I started asking two weeks before I needed to set them up, and everyone managed to work out dependencies among themselves quite well, but I would have loved to have time to do a test install to eliminate collisions in the registry.
  • Make sure you get access to machines the day before workshops. That day was attended by all but two workshop presenters (those presenting using live dvds) and solved many problems.
  • Getting things printed was not difficult, but half the workshops chose not to provide printed material. This makes alot of sense, provided materials can be provided for download. Having a handful of cd's to hand out would have gone a long way as well.

General

  • Of 401 conference delegates we had 188 workshop registrations; more workshops would have been appropriate.
  • One bit of feedback I heard a lot of during the conference is that people would like to have been able to attend more workshops.
  • Our market is fairly immature, but more workshops over more days would have gone over very well.

WMS Shootout

The WMS Shootout is a presentation comparing different WMS (and WFS?) implementations.

  • It was proposed as a Abstract, and was ranked by the community as the most popular presentation, and so was moved to the closing plenary session (in front of everyone, instead of within one of the steams).
  • While the Shootout was mentioned in early marketing, hoping that it would indeed be presented again in 2009, it would have been better to plan for the Shootout much earlier. Ideally this should become a permanent fixture of FOSS4G events, with a carry over of experience from year to year. This will allow it to be included more prominently in early FOSS4G marketing material as a FOSS4G drawcard. It can also be slotted into the program right from the start.

Abstract Selection

  • Make it a criteria of Abstract Submission that submitters accept a license to have their slides from the presentation, and a video of their presentation made available via Creative Commons. (It is messy to have to collect this afterwards).
  • 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.
  • Save the date when presentation was submitted. (It is useful to see when abstracts are being submitted.)
  • 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. (Country). Make sure the Country names is a pull down list which is the same as for registrations.
  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 vote for just one abstract. We should also check the votes to verify people are not rigging the voting.
  • Having the community rank the abstracts was very successful. We did not get anyone challenging our selection choice, which was an issue in previous years. It also made it much easier for the abstract selection committee, as we had so many good abstracts to choose from.
  • Abstracts submission form should collect:
    • Title
    • Authors (multiple, some presentations had up to 3 presenters)
    • Abstract
    • Affiliation (company that authors work for. We aimed to have a spread of organisations represented)
    • email address (you will want to contact presenters afterwards)
    • Country (you may wish to have some balance of presentations across countries)
    • Tags (usefull for public voting, especially for 2010 where a huge number of presentations is expected. People could more easily vote on topics they care about)
    • Submission date (track the date automatically, it's always interesting afterwards when the people actually submitted their abstracts)
    • Accept that presentation material to be published unter CC (probably CC-BY or CC-BY-SA) (Add a checkbox that the presentation material (and possibly recordings) will be published under Creative Commons. Hunting for the permission afterwards is messy)

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.

Comparison presentations

Delegates who voted for the FOSS4G 2009 presentations ranked the OSGeo comparison projects very highly, which is something I suggest presenters take note of, because competition for speaking slots is fierce.

At FOSS4G 2009, 183 quality presentations were submitted, and there was only 85 speaking slots. In 2010 it is likely to be much harder to be selected to present, as there is expected to be 2 to 3 times more delegates and many more hopeful presenters.

In 2009 the community ranked potential presentations, and some of the highest ranked presentations compared popular packages. Unfortunately, there were only a few of these types of presentations.

The presentations were:

  • Ranked 2: The WMS Performance Shootout
  • Ranked 8: PostGIS and Oracle Spatial
  • Ranked 9: There is no alternative to Openlayers...? (discussing OpenLayers vs other AJAX clients)

The moral to the story is that delegates want to see how different projects compare, and to date we have had a shortage of such presentations (partly because they are a lot of work to set up).

However, I strongly suggest that projects start teaming together to put together such presentations for 2010.

In particular, I'd love to see comparisons between:

  • Geospatial Desktop applications
  • Geospatial Browser based applications
  • Geospatial Servers (WMS, WFS, Tiled Services at the very least)

The comparisons could cover some or all of:

  • performance
  • robustness
  • features
  • ease of setup or use

The tests should not be restricted to Open Source, but be open to proprietary vendors too. (ESRI and ERDAS were invited to participate in the 2009 WMS shootout, and it seems likely they will participate in 2010).

Schedule

  • Make sure you have backup presenters. We had (Harley to confirm) over 10 speakers drop out before the conference.
  • Make sure you have back up presenters for keynotes and lightening talks. (These will likely be one of your other presenters).
  • Tell each presenter what time they are presenting. Through mis-communication one of our keynotes got the day wrong, and we had to do last minute juggling to the program to fit him in.
  • Make sure all speakers, tutorial presenters and workshop presenters have registered for the conference. We discovered at the last minute that some of the tutorial presenters were not registered.
  • When collecting personal details from presenters, ensure to collect an email address or similar which can be linked back to the registration list so you can cross check registrations. We had to do this manually, which was difficult.
  • One (Government Manager) wished to see an overview presentation at the start of the conference, so that he could decide which presentations should be viewed through the rest of the conference. This could be a very compelling, plenary presentation: "FOSS4G themes in a nutshell".

Birds of a Feather

  • We had one official "Birds of a Feather" session on Thursday afternoon. We had a wiki page for people to sign up for the Birds of a Feather before hand, but this wasn't used much. http://wiki.osgeo.org/wiki/FOSS4G_2009_BirdsOfAFeather
  • We also had sign up sheets at the OSGeo stand, and that was used. We had many people wanting to go to a number of the sessions, and a couple of sessions were moved to different timeslots.
  • The description "Birds of a Feather" was not understood by many people and they needed to have the term explained to them. This is an issue for people looking at the program before hand and wanting to determine whether they should come to the session or not. Maybe use "Interest Groups" instead.
  • I, Cameron Shorter, organised 5 meetings of like minded people over dinner, breakfast and during the code sprint. (Meetings around Defence, Water, SDI implementers, GeoSpatial Businesses, OSGeo Marketing). I had the advantage of having access to the registration list, and hence could invite people individually. Even so, my skim over the lists was rushed and I'm sure I missed half the people who should have been at these gatherings. These meetings were very successful, with almost everyone invited attending, and I had many thank me for inviting them and noting that they found the meetings very valuable. So lessons for next year:
    • Provide a list of local restaurants beforehand, and invite delegates to set up "Interest Group" meetings at these restaurants for breakfast and dinner during the conference.
    • Someone with access to the delegate list should go through and email delegates individually and suggest meetings they may be interested in. (I used email domain names and my personal knowledge of delegate affiliations to identify likely interest). Someone also suggested that we could do some smart analysis of how people vote for abstracts. Alternatively, we could ask delegates to tick areas of interest when the register.
    • Note that the size of the group effects its effectiveness. A group of 8 allows people to talk with each other. If you have a group of 20, then you will want to give people a chance to move around. (For a dinner group of 25, we had people mingle while having drinks before dinner, then invited delegates to change seats between dinner and desert).
    • Jeff McKenna made a good point that these meetings should not be open:
"These 'invite only' meetings by the LOC at FOSS4G2009 left many of us who were not invited to meetings like 'GeoSpatial Businesses' (including myself and others that I know) feel that we were unwanted, after traveling across the world and spending so much money to be there. These meetings are a good idea, but they must be open to everyone to attend."

Installfest

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. Anyone can view the metrics at http://www.google.com/analytics/ user: foss4g2 password: foss4g2009

The master account is: foss4g@gmail.com. The organising committee know the password.

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 so we ramped up marketing in Asian marketing. As a consequence, we doubled the number of Asian delegates at FOSS4G this year over last year.

Google Docs

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

Delegate Feedback

Delegate Profile

This spreadsheet provides breakdown of registrations for 2007, 2008, 2009 based on:

  • Registration Date
  • Geographic Location
  • Job Profile
  • Reason for attending

http://spreadsheets.google.com/ccc?key=0Al9zh8DjmU_RdEZoOUtSeVZRVWtKQzV6R2N5ekdSdlE&hl=en_GB#

Some of these metrics were discussed in the 2009 Chair opening speech: http://2009.foss4g.org/speakers/#Cameron_Shorter

FOSS4G 2008

Back to Conference_Committee

This page is a collection of information, comments, and suggestions, based on the planning, organizing, and hosting of the FOSS4G 2008 conference. The intent is to provide a resource that can be used by organizers of future FOSS4G conferences. This is not a forum for conference attendees to comment on the conference. Use FOSS4G2008_Comments for that.

Bidding

Timetable

Money

Sponsorships

Complimentary Registrations and Volunteers

Workshop Pricing

Registration

Support For Some Attendees

Scams

Discounts

Breakdown by Country

Attendance

At the Conference

Within the Conference

Within the Code Sprint

Marketing

The Mail-out

How People Heard about FOSS4G2007

Local / Regional / International

Use Proxies

Local Marketing is Key

Web Site & Program

Lists are Important

Press Releases

Social Venues

Conference Venue

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

Suggestion for 2009:

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

Audio-Visual

Computers, networking

Internet traffic

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

Quirks

Accommodation

Transportation

Workshops and Labs

Workshops and labs were again very popular. In Cape Town, it presented a chance for many people to shake off their fears of working with FOSS. There is some talk of not running the 1.5 hour labs in 2009. Consider that some of the labs had over 70 people attending. There is certainly a demand. This needs to be balanced though. 2008 had too many workshops and labs - 15 workshops and 20 labs in total. This became difficult to manage logistically and technically - there are so many factors that can go wrong!

Workshop Committee

This is a big task, even if at 2009, Sydney decides to scale back on the workshops and labs.

We had it roughly break out as follows:

A person responsible for the technical side of the workshops and labs (software, computer setup etc) A person responsible for the logistical side (comms with the IT suppliers, other suppliers) Advisor from 2007/ OSGeo 2008 Conference Chair, to ensure integration with the rest of the conference

For the scale of 2008, we probably needed another LOC member technically involved.

We used formal conference volunteers to an extent, but if we had more more of them, they could have been put to work quite happily on doing tests and installs.

The amazing part was the willingness to help out evident in the FOSS4G community. A gang of helpers made sure that we were all systems go for Monday by spending most of their Sunday helping to install, configure, test stuff. No complaining, just doing. Brilliant! Ideally, this spirit should not need to be tested though. Early preparation will avoid this to some extent.

Terminology

Call for Workshops

Timing

As early as possible to allow maximum time for instructors and workshop committee to prepare (though some instructors will always leave things to the last - human nature!). It should go out in a month or two's time from now - preferably before year end.

Format of the Call

We put out a document in pdf, odt and word that required instructors to fill out a bunch of info that would help us to assess the session. Best to read it at [1].

Results of the Call

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

Selection Process

Philosophy

Do you want to cater for the most established projects, in the hope of filling up rooms, at the risk of becoming stale? Do you wish to introduce new software tools to the audience and give a chance to emerging projects? Well, a mix of both seems appropriate, but one has to judge the potential audience a bit. For Cape Town we had local knowledge, for example, that MapWindow GIS was gaining some popularity in certain circles. As a result, we made sure that this project had several slots in the programme. The risk of having less well known projects as workshops is that attendance might be lower, affecting the conference bottom line. Labs are an opportunity to showcase such projects.

Ranking and Decisions

Google Docs was a neat way to do things. We each ranked each proposal on a scale of 1 to 5, based on importance to the FOSS4G community, likely interest, likely audience size and stated requirements, We added comments and then compared scores, imparted some local knowledge and gave an initial rank sort. We also considered whether some of the workshop proposals could be undertaken as labs.

Ot of this came a second rank, which ended up close to the eventual program. Instructors were then invited and given time to consider how serious they were about participating, which included registering on the conference site. Some on the list pulled out and were replaced from the next in line from the rankings.

Communication with Instructors

Instructors should be *forced* onto the workshop-dev mail list - at 2008, some instructors did not join the list and were a bit incommunicado. Personal communications cannot be underestimated too.

Preparation Process

Actually there is probably some sense in having a few stages to the workshop/lab development process. Probably difficult to do, but perhaps ensure that the material to be presented (software, data, printouts, slides etc) are ready at least a month before the time. Some projects want to show the latest and greatest features at the workshop or lab, but this creates stress and risk. We had workshop / lab presenters compiling their code for their session the night before. All in the spirit of things, but very stressful indeed. Avoid. Determinedly.

Venues

At Cape Town, we had 2 big, dedicated venues at the main conference centre plus the main auditorium for one workshop, one venue at the hotel where most delegates were staying and two venues at the University, 15 minutes drive away.

Venue TypePro'sCon's
Large dedicated rooms at CTICCControl! We could put in freshly imaged computers, our own LAN, good AV facilities, nice desks. Their size allowed us to hold large workshops and labs (capability for 100 pax, but max attendance was somewhere in the region of 80 folk). These rooms also acted (unintentionally) as places where folk could go and catch up on e-mail, have some quiet time, etc, when they were not in useA little bit soulless, especially if not full. Some instructors felt un-engaged by the audience in these large venues
Auditorium at CTICCUmmm, an extra venue at no extra cost?Power supply problems, network issues, cavernous place to instruct a few dozen folk. Not sure if it was a success to have a workshop where people had to supply their own notebooks - created config issues
HotelThis was pretty much the same as the main venues: we had control, access and pleasant environment, plus the advantage of not being too huge. Plus, tea and snacks were thrown in as part of the price.A 5 minute walk from the CTICC, not a big problem, but causes delays
UniversityThe venues were a bit more intimate - instructors could engage with attendees more easily. Felt a lot less "corporate". Nice opportunity to raise awareness of FOSS4G. Lab owners were very enthusiastic and helpfulNo Control! We had to work with PC's with no idea what was on them, other than the OS, and no ability to clear the environment. Who knows what students are doing on lab PC's? Network access and internet connectivity was THE major issue. The university bandwidth was limited such that one workshop in particular did not really work. Also, Internet access was controlled by a proxy, which required usernames and passwords, which the network admins were not too keen to hand out and which caused great annoyance for Firefox users. Transport to the venues was problematic, particularly if folk missed the buses

The logistical and control hurdles of having workshops at a University were big. Much better to keep venues in one place if possible, or otherwise have them in close walking distance of each other. There is a lot to be said for having 'clean' venues, where you have control over how things work. Try to encourage more interaction through careful choice and setup of venue

Laptop Based Workshops

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

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

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

Computers and Networks

Rule number 1: Work with a good technology supplier. We had the most amazing experience with our main IT suppliers - they were flexible, helpful, committed and technically sound. Okay, so the bandwidth was used up at times, but that had more to do with the cost of connectivity than the IT team.

Our approach was to allow several ways to present a workshop or lab. Instructors could build a LiveDVD / LiveUSB and run the session from that. Alternatively, instructors could prepare a VMWare image and run the session from VMWare Player. Thirdly, and most commonly, instructors could provide some software (and data) and provide setup instructions. We then ran through the setup on 2 slightly different machines, and then our IT supplier imaged this setup over the 98 other machines.

The LiveDVD/LiveUSB approach worked pretty well, putting all the onus onto the instructors to be ready. this approach incurs a higher hardware cost, as one needs more RAM.

The VMWare approach was mixed. It was most successful when a thin Linux image was used. Windows based images were huge, and thus difficult to upload/download in preparation. Also, the VMWare approach definitely requires more punchy machines - minimum 2Gb RAM. With enough preparation time and upload/download bandwidth, this is a very solid approach though one needs to be careful to make sure networking is setup properly.

The third approach worked well on the whole. We could prepare the environment quite well if instructors came to the party early with their requirements and instructions. One thing that we tried to a limited extent was opening up a VNC/Remote Desktop Connection to the machines that we were preparing. Given more time, we could have had a slot where each instructor made sure that their setup worked. Agreement on port numbers beforehand was useful for this approach. This approach came a bit unstuck when instructors were not prepared well in advance. Installing a bunch of software across 50 machines the night before a workshop or lab is not conducive to good heart health. If this approach is followed, one thing that worked really well was having an identical network share on each machine. This allowed us to rapidly install software in-situ through an almost peer-to-peer method.

Whichever approach is followed, it is well worth having a conference Server, where last minute things can be served from, whether they be a patch, a set of data or a set of documents.

Software

We ran Windows XP as a base install. This worked quite well for the South African environment and for the particular conference, which included a lot of folk who were less exposed to Linux. I feel that this choice was determined by our audience in the end. Some FOSS4G attendees were annoyed by the use of Win XP in this way, but it was a pragmatic approach that worked, and also allowed certain FOSS4G projects that are Windows based to gain exposure. We needed to introduce many people to FOSS4G, not necessarily the whole FOSS universe out there. Perhaps the audience will be different in Sydney, but the choice does need to be carefully weighed up. We chose to offer a bridge into FOSS for the most people.

MS4W, OSGeo4W, PostGIS, Java, Tomcat, Firefox, Google Earth covered a lot of bases and were all easy to install and work with on Win XP.

Printed Handouts

2008 provided printed handouts where instructors wished them to be provided. One issue is that for labs it is difficult to know how many to print, for the labs are essentially walk in affairs. Feedback from attendees at labs and workshops suggests that, on the whole, printed material is desirable. One downside to having printed material is that attendees often tend to race ahead of the instructor, which can be problematic if the workshop or lab content is complex or likely to cause problems if an attendee misses a step.

We found a very helpful professional printshop near (i.e. 2 minutes walk) to the conference venue. They were flexible, accommodating and very professional. We organised a kind of printing "slush fund" at the printshop, which was capped at a certain level.

On another track, printed material offers a sponsorship opportunity...

Evaluation Forms

We provided evaluation forms, in paper format, for all workshops and labs. However, the use of paper forms has to end - it requires someone post-processing each and every one to convert to some digital format for sharing. A web form/survey could be used, since all workshops attendees are in front of a computer anyway. I think this is a must for 2009.

Presentations

Call for Papers

Academic track

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

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

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

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

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

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

Suggestions for 2009:

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

General track

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

Submission Process

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

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

Community Ranking Process

Building Sessions

Cancellations

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

Posters

Wiki

Conference Evaluation

Workshop Evaluations

Onsite Staff

Program handouts etc

  • convenient small flyer, nice to carry around
  • presenter names would be desired (small font)

Conference website software

For the first time, OSGeo is making use of the Open Conference Systems (OCS) software to 'manage' a FOSS4G conference.

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

  • See FOSS4G2008_Site_Upgrade
  • and FOSS4G2008_Committee_Issues#OCS_website_management
  • Limitations (to be fixed for 2009):
    • No list of participants easily extractable
    • No online session navigation (as supported Indico, see www.foss4g2006.org)
    • When a user's email is updated in OCS, this is not automatically reflected in the submissions of that user. There was one case where an author changed his email in his user profile, however his paper notifications were still sent to the old email address. As a track director, there is no way of knowing that the author did not receive the notification.

FOSS4G 2007

FOSS4G 2007 Lessons Learned

Retrieved from "http://wiki.osgeo.org/wiki/FOSS4G_Manual"
Personal tools