[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Debconf-team] What is "ad hoc"? [Was, Re: General schedule proposal for dc15]

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 <madduck@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

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/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: