On Sun, Sep 21, 2014 at 11:14:19AM +0200, Margarita Manterola wrote: > On Sun, Sep 21, 2014 at 10:19 AM, martin f krafft <madd...@debconf.org> wrote: > > We don't really have much weekend time, especially considering tnat > > we are planning an opening weekend. The next Saturday is already the > > final conference day and we are off on Sunday. I believe just three > > days of talks with all the other days without talks in the afternoon > > will mean too few slots. Generally, I'd be fine with that, but we'd > > have to select very strongly based on quality, and I am not sure we > > are ready to do this.
> 8 hours during weekends and 3 hours during weekdays add up to: 3*8 + > 4*3 = 36 hours of talks. With 2 talkrooms, that's 72 talk slots (the > amount of talks may vary depending on talk length, which is a > different thing). > I don't think 72 slots is "too few". Particularly if we are then going > to let people have ad-hoc talks about whatever. What does "ad-hoc talk" mean in this case? I was personally not very happy with the way the ad-hoc scheduling was done this year. My vision for "ad hoc" is "give hackers space and time in which to break out into groups and work collaboratively". I think for DC14, it really wound up being "create a whole added track of late-scheduled talks where people would present, with streaming to the world and videos and slides". This cut into the time set aside for collaboration, which I view as a net negative. I don't think we should have ad-hoc /talks/ at all, and we should banish the phrase "ad-hoc talk" from our vocabulary. The purpose of the ad-hoc schedule shouldn't be to let more people give presentations that weren't selected by the talks team, but to let people have workshops, discussion sessions, hack sessions, etc. For a concrete example of this at DC14: there was an ad-hoc session scheduled about UEFI Secure Boot, with the intention of getting the folks into one room who held various pieces of the puzzle needed to get support off the ground in Debian. This needed to be explicitly scheduled with a time and place; but it was scheduled in a talk room, was videoed, etc., and so the net result was that it had a large audience of interested onlookers and the first 15 minutes of the session was spent on an "introduction to Secure Boot" for the audience, instead of on the stakeholders working out the details they needed to. My opinion is that 72 slots being too few or enough is very dependent on how the ad-hoc time is used. I think that if we wanted to hold to a rule that ad-hoc time is *not* for overflow talks rejected by the talks team, 72 slots is probably too few and would result in a lot of pressure on the team to allow ad hoc to be used as overflow. So I would argue that we should have more scheduled talk slots in order to avoid this outcome. However, such a plan would also require buy-in from the whole talks team about what sessions will be scheduled and how. This would mean avoiding telling submitters of rejected talks that they can schedule them ad-hoc; it also means the talks team would need to be mindful that there *isn't* overflow available for additional talks, in deciding what talks to accept or reject. (I.e., if a talk proposal is rejected with the intent that it be ad hoc instead, it needs to be something that would fit such an ad-hoc format.) And it means the folks doing the on-the-ground scheduling of ad-hoc sessions would also need to be on board with this. I don't know if my view on this is the prevailing one; but I do think, based on my DC14 experience, that it's something that should be talked through well in advance of the conference (i.e., at the scheduling phase), to make sure everyone is on the same page. Obviously people are each going to have their own individual ideas about what the focus of DebConf should be; the problem is that if each person acts according to their own preference, we get a very muddled result that is less good than any of the individual ideas. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
_______________________________________________ Debconf-team mailing list Debconf-team@lists.debconf.org http://lists.debconf.org/mailman/listinfo/debconf-team
