Difference between revisions of "FOSS4G 2013 Lessons Learned"

From OSGeo
Jump to navigation Jump to search
 
(12 intermediate revisions by 5 users not shown)
Line 1: Line 1:
==Sponsorship==
+
'' NOTE: During a wrap up meeting in November after the event, the local committee members compiled many thoughts and recommendations: Please see [[FOSS4G2013 Reflections by the LOC]] ''
  
This year we had a "supporter" sponsorship level, which was aimed at those companies who would not want a stand, but would want some minor branding on the website and at the event. This was very popular and we'd recommend it to future organisers.
+
==Workshop Booking==
  
==Website==
+
Workshops are limited by the size specified by the author, and also the size of the rooms available in the venue. It might be a good idea to make the importance of size more clear when asking for workshop submissions (SF). There's a juggling act to do when assigning workshops to rooms (and hence knowing the maximum number of people who can book onto it), and it's also important to consider the expected popularity of each workshop. Expect to have to move some around when bookings come in.
  
A submission notification should be provided within the service for submitting abstract, workshop, etc. An automatic reply mail would do the trick. We did have a section on the web page leading to the submission section that said people wouldn't receive confirmation, but either they missed this or wanted to check anyway, so it ended up causing more work.
+
==Dates==
  
==Publicity==
+
Ensure the program is out before the end of the early bird deadline as people may wish to choose which day(s) they attend on the basis of the program.
  
We've used Lanyrd to publicise the event alongside the "usual" channels, and also Eventbrite for dealing with the free hackathon registration.
+
==Communications==
  
==Paper Selection Methodology==
+
'''You cannot please the whole community all of the time!''' so don't try. The mailing lists can be pretty critical and trying to patiently explain each decision may sometimes just stir up more criticism, avoid getting into public mail disputes on the list. It would be good to have more Board participation on some of the contentious topics.
 
 
The OSGeo community is very passionate about openness, so the methodology needs to be made as explicit and open as possible. Where additional filtering on top of the community vote is required (which it invariably is) then this needs to be explained clearly in the wiki. There probably ought to be an established methodology for doing this, which should be recorded in the [[FOSS4G Cookbook]].
 
 
 
==Workshop Booking===
 
 
 
Workshops are limited by the size specified by the author, and also the size of the rooms available in the venue. There's a juggling act to do when assigning workshops to rooms (and hence knowing the maximum number of people who can book onto it), and it's also important to consider the expected popularity of each workshop. Expect to have to move some around when bookings come in.
 
 
 
==Dates==
 
 
 
Ensure the program is out before the end of the early bird deadline as people may wish to choose which day(s) they attend on the basis of the program.
 
  
 
== Previous Years Lessons Learned  ==
 
== Previous Years Lessons Learned  ==
  
 +
* [[FOSS4G2013 Reflections by the LOC|2013]]
 
* [[FOSS4G 2012 Lessons Learned|2012]]
 
* [[FOSS4G 2012 Lessons Learned|2012]]
 
* [[FOSS4G 2011 Lessons Learned|2011]]
 
* [[FOSS4G 2011 Lessons Learned|2011]]

Latest revision as of 12:35, 2 February 2015

NOTE: During a wrap up meeting in November after the event, the local committee members compiled many thoughts and recommendations: Please see FOSS4G2013 Reflections by the LOC

Workshop Booking

Workshops are limited by the size specified by the author, and also the size of the rooms available in the venue. It might be a good idea to make the importance of size more clear when asking for workshop submissions (SF). There's a juggling act to do when assigning workshops to rooms (and hence knowing the maximum number of people who can book onto it), and it's also important to consider the expected popularity of each workshop. Expect to have to move some around when bookings come in.

Dates

Ensure the program is out before the end of the early bird deadline as people may wish to choose which day(s) they attend on the basis of the program.

Communications

You cannot please the whole community all of the time! so don't try. The mailing lists can be pretty critical and trying to patiently explain each decision may sometimes just stir up more criticism, avoid getting into public mail disputes on the list. It would be good to have more Board participation on some of the contentious topics.

Previous Years Lessons Learned