On 22 September 2014 05:42, Steve Langasek <vor...@debian.org> wrote:
> 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".
FWIW, that's what I expected "ad-hoc" to mean too. "Scheduling"
"ad-hoc" talks seems kind of like a contradiction in terms to me.
> 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.
That said, it was impressive (to me anyway) that Linus's Q&A could go
from a random attendees idea to a well-attended, streamed and recorded
talk in just a couple of days. It might be kind-of cool to allow for
"late" talks on sufficiently interesting subjects to be able to be
scheduled, even down to a couple of days before. In the past you've
had to submit proposals months before the conference (Dec 2005 for
DebConf 6's CFP, DC6 was then five months later in May), so there's
plenty of time for new stuff to happen between the CFP deadline and
the conference to want to add new topics. DC14's CFP closed just a bit
over a month before DC14 by contrast; guess it depends on which way
you want to do things.
> I don't think we should have ad-hoc /talks/ at all, and we should banish the
Actually, what if you ran, say, three CFPs? Assuming 75 slots, run one
with a deadline in March/April 2014 selecting at least 15 but no more
than 45 talks; a second ending in June/July selecting an additional
25-55 talks getting the total up to 60-70; and then leaving the final
CFP open during the conference for the remaining 5-15 slots (that just
become empty rooms / hack time if they're not filled)?
It'd be easy to reject talks with poor descriptions in the first CFP,
because they could just resubmit in the second one; it'd be at least
possible to get your talk selected early, so you could know you were
speaking before booking flights; you could populate the schedule a
little a bit early, so people could see that before booking flights;
you'd guarantee room for any interesting topics people hadn't thought
of until just before the conference, and you'd have some (minimal)
room for /actual/ ad-hoc talks.
> 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.
Some (most?) of those don't seem like they should need to be ad-hoc?
If you want to get all the UEFI folks in a room together to work on
stuff, wouldn't it make more sense to work out a time/place for that
at least a few days before debconf?
> 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.
That seems like a "description" problem -- if you only know that
there's something going on in a room and it's about "UEFI Secure
Boot", it's an "ad-hoc session", a "BoF", and the detailed topic is
"Work out what we need to do next to move forward UEFI Secure Boot
support in Debian." how are you meant to know that it's not intended
for people interested in the topic, but ignorant?
Even then, it'd be possible to start the session with "hi, I see a lot
of people here. this is intended to be a detailed session on how to
actually make UEFI secure boot stuff happen, so if you're not already
deeply familiar with how it works, or maintaining one of the core
packages involved in the boot (grub, kernel, initramfs, ...), this
will probably be over your head and you might enjoy one of the other
sessions more".
> My opinion is that 72 slots being too few or enough is very dependent on how
> the ad-hoc time is used.
It might be better to split it up as a full matrix -- style (talks,
workshops, bofs) versus preparedness (known six-months out, known
one-month out, known 24 hours out)?
I think there were around 105 45m slots at DC14 (Mon-Sat, ignoring the
shorts days on the leading weekend and final Sunday)? There was also
kind-of a 30m "Hacking" slot between 15:15 and 16:00 most days, so
that's an additional 15 half sized slots, I guess.
I guess I'm distinguishing the categories as something like:
- talks (and panels and q&a) -- slide projector, lots of attendees
- workshops -- specified goal, ability to do both talk and do work,
tables ideally, not too many people
- BoFs -- just talking, could do it over drinks or outside
- hacking -- completely free form
Video of workshops would just be a pain (though screencasts could be
fun, and a lightning talk or written summary would be a good idea).
Video/audio of BoFs can be useful, but given the whole passing around
the microphone deal, is probably too inconvenient.
Doing too many talks concurrently's a bad idea -- the point is to get
the info from the speaker to a bunch of people after all. But you can
do a few workshops at once, because you want to keep the numbers there
small anyway so that everyone can still talk to each other. Presumably
you wouldn't want more than 30 workshops happening at once under any
circumstances, and five or ten is probably a more reasonable maximum.
Workshops are arguably a harder scheduling problem -- with talks, you
only /need/ the presenter there, and with BoFs you don't even have
that constraint, although it's good to have /someone/ who is willing
to lead a discussion. For workshops though, you might not get anywhere
if you can't get half a dozen particular people in the room at the
same time.
> 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,
I guess I wonder if it would make sense to call it something other
than a "talks" team if the idea is they should be dealing with BoFs
and workshops and such? "Sessions team" or something? Otherwise it
doesn't seem that surprising that if you've got a "talks" team doing
the scheduling, you end up with a lot of talks or people thinking
things are talks...
> 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;
(I don't understand why you'd ever accept an ad-hoc proposal for a
talk that was already rejected. I mean, if the proposal improved
substantially in the meantime, sure, but that's really just having an
iterative CFP, isn't it?)
A bunch of this seems like it might just be the result of compressing
what was a two-week DebCamp (hacking/BoFs/workshops) + DebConf (talks)
into a bit over one week, but still trying to say "yes" to just as
much stuff. I think DC15 is also only seven days (plus day trip), so
will presumably face similar issues...
Anyway, maybe some of the above makes sense / is interesting? If it
helps, here's a strawman proposal for what things might look like more
specifically if you did something like the above:
- Feb-Mar: 1st CFP, accepting 15 to 45 talks
- Apr: add first round of accepted talks to website
- May: bursaries approvals
- Jun: attendance reconfirmation deadline
- Jun-Jul: 2nd CFP, accepting 25 to 55 talks; also accepting workshop
proposals (up to 25?)
- late July: post accepted talks (~60-70), post full schedule of
talks and workshops
- Aug: open up wiki for people to indicate interest in BoFs
- At debconf (ie, the following is the "ad-hoc" stuff):
- open scheduling for BoFs (no reserved spaces)
- workshop slots scheduled by "talks" team 24-36 hours beforehand
- proposals for ad-hoc talks accepted, scheduled the night before
the talk slot
Average day at the conference might look something like:
10-11 Talk 1a, 1b, 1c
11-12 Talk 2a, 2b, 2c
12-14 Lunch, BoFs
14-15 Talk 3a, 3b, 3c
15-16 Talk 4a, 4b, 4c
16-18 Hacking, BoFs
18-20 Dinner, BoFs
20-22 Free time, Hacking, BoFs
08-10 Workshop 1a, 1b, 1c, 1d, 1e (breakfast)
10-12 Workshop 2d, 2e (morning talks)
14-16 Workshop 3d, 3e (afternoon talks)
16-18 Workshop 4a, 4b, 4c (hacking time)
20-22 Workshop 5d, 5e (after dinner)
If you ran that schedule Mon, Tue, Thu, Fri, Sat, that's 60 one-hour
talk slots and 70 two-hour workshop slots, split across three talk
rooms (a, b, c) between 8am and 6pm, and two "reserved" areas in the
hacklabs (d, e) between 8am and 10pm, say, with the opening Sat and
Sun planned out differently and adding an extra 15 talk slots to get
up to 75 total (six talks on Saturday, nine on Sunday maybe?)... I'm
assuming you'd fit the "closing" stuff into the 16-18 slot on
Saturday, so as keep the extra talk slots.
Have the first CFP fill in the 14-15 and 15-16 talk slots (early
submitters get the easiest time slots ;) say. Workshops accepted as
part of the second CFP fill in the 8-10, 14-16 and 20-22 timeslots on
Mon-Thu with submitters being able to specify a preference -- that way
they don't risk accidently conflicting with talks accepted in the 2nd
CFP, and at worse can choose early or late slots to avoid conflicting
with the 1st CFP's talks. Reserve the rest of the workshop slots for
ad-hoc workshops planned during debconf. Perhaps reserve room c on the
final Saturday for a handful of ad-hoc talks.
That's a pretty intense week (potentially 8am-10pm every day, albeit
with two hours for lunch and another two for dinner), but if you don't
want it to be that packed, you'd either have to take stuff out --
fewer or shorter talks, less time for food, less collaboration time --
or you'd have to extend the conference timeframe (add back a DebCamp
week eg)...
Going through the dc14 schedule via ical [0], and manually reviewing I count:
6 "plenary" events (where it mightn't make sense to schedule anything
in parallel)
Welcome talk
Debian in the Dark Ages of Free Software
Q&A with Linus Torvalds
Group photo
Lightning Talks
Closing ceremony
5 "workshop"-type things:
UEFI Secure Boot
DebConf organisation working group
DebConf15 workgroup
Debian Python team git conversion
Finding solutions for reproducible builds BoF
36 "presentations"
18 "discussions"
29 "bofs"
Counting plenary events as 3 talks each, that's 18+36+18 = 72 talk
slots, which works with the above. Assuming all of the bofs were
actually "workshops" would give 34 workshops, though presumably some
of them could equally well have been done over dinner or similar...
There'd still be 36 workshop slots left over though, which would
presumably would be an improvement over dc14?
Cheers,
aj
[0] python:
import icalendar
def typesums(y):
r = {}
for a in y.walk():
t = a.get("X-TYPE")
if t is None: continue
if t not in r: r[t] = []
r[t].append(a.get("SUMMARY"))
return r
c = icalendar.Calendar.from_ical(open('debconf14.ical').read())
ts = typesums(c)
for t in ts:
print t.encode('utf8'), len(ts[t])
for s in ts[t]:
print " ", s.encode('utf8')
--
Anthony Towns <a...@erisian.com.au>
_______________________________________________
Debconf-team mailing list
Debconf-team@lists.debconf.org
http://lists.debconf.org/mailman/listinfo/debconf-team
