Hey, I think this was an interesting discussion about the length of the conference with 2 vs. 3 days. In the end it does look like that while squeezing enough talks into two days is be viable with the current interest in the conference, doing so might however change the character of the conference. We are now at a point where we should soon finalize the venue booking. And while I am not totally set on it, I am actually thinking of staying with 3 core days for next year at least. The main reason for this are: * more time for social events/hallway track * we just moved down to 3 from 4 days last year * I am not a fan of e.g. cutting the intern lightning talks (in the very least it is a good learning experience) That would give us 3 core days (again Friday-Sunday) and 3 BoF days (having more BoF days seems unreasonable to me). If there is interest we can probably organize more rooms for teams that want to do a proper hackfest for the whole week. Benjamin On Do, 2015-11-05 at 19:03 +0000, Allan Day wrote:
Huge thanks to the team that are putting on GUADEC this year. It's fantastic that you've stepped up, and Karlsruhe looks like a cool city! I've been involved in the papers committee for a fair few years now, and I've been involved in doing hte conference schedule for at least the past 3/4 years. I was interested to see that your bid proposes only having two core days for GUADEC next year. Until 2014, GUADEC had 4 core days. Then, this year, we switched to 3 days. This was a bit of a challenge for the schedule: we just managed to squeeze everything in, but only just. If we want to go down to two core days, we'll probably have to radically rethink the schedule. Possibilities might involve cutting the lightning talks, and/or cutting the length of the talks. It seems like a good idea to talk about this early on. I'll also say that I'm a little hesitant about cutting down the length of the core days from a social point of view, and that it would be a big change from the 4 day conference we were holding until just last year. That's not to say that there might not be advantages to the change, but it probably deserves some discussion.
Attachment:
signature.asc
Description: This is a digitally signed message part