Difference between revisions of "FOSS4G 2011 Lessons Learned"
| Line 1: | Line 1: | ||
[[FOSS4G 2011|FOSS4G 2011 Home]] | [[FOSS4G 2011|FOSS4G 2011 Home]] | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Previous Years Lessons Learned == | == Previous Years Lessons Learned == | ||
| Line 42: | Line 32: | ||
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. | 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 === | === Paper selection === | ||
Revision as of 12:54, 7 June 2011
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!!
Logo
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.
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.