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

Re: [Debconf-team] A proposal about scheduling for DC14

Hi Gunnar,

On Tue, May 20, 2014 at 06:04:06PM -0500, Gunnar Wolf wrote:

> > Fri, August 22:		Arrival day. Dorm check in available after noon.
> > 			Minimal hacklabs. No talks.
> > Sat, August 23:		First day of conference. Opening immediately after
> > 			brunch. Slots for 4 talks afterwards (inc DPL).
> > Sun, August 24:		Full day of talks; start post brunch,
> > 			15 slots.

> Hmm... I would assume most people travelling from far will travel
> during the weekend, as taking time off work is better explained when
> it is constrained to a week. This might be related to the fact that
> it's what I will be doing — And my travel is among the shortest for
> the international attendees.  I would use Saturday as a soft-day, that
> is, a hack day + BoF day for people that already arrived, but a buffer
> day for the rest. Yes, we often have an arrival day marked as such,
> but have people dripping in during all of DebCamp... So I think having
> a soft day at the beginning would be more suited to what we have come
> to expect.

> At least, what I have come to expect. But, of course, I'm trying not
> to make this day about myself (and rather, make it about the whole
> group).

FYI, we do have some data already about this, namely the arrival/departure
dates that sponsored attendees have entered when registering.  For each
night of sponsored accommodation, we have:

  Date       | # sponsored
  2014-08-22 | 126
  2014-08-23 | 134
  2014-08-24 | 133
  2014-08-25 | 136
  2014-08-26 | 136
  2014-08-27 | 136
  2014-08-28 | 134
  2014-08-29 | 131
  2014-08-30 | 125
  2014-08-31 |  93

So contrary to my own expectation that people would tend to arrive over the
weekend, the numbers suggest that most attendees will already be there
Friday night.

> Right, you set Saturday as a day with four talks only... But I would
> push "strong" talks, such as the DPL's to Sunday.

There is a further consideration here, which is that our plenary room seats
200 people total.  We didn't take a larger plenary room, since this was
going to be a major price bump and we had assumed that plenaries would only
be at the beginning and end when overall attendance was lower.  However, the
pricing for this space changed since we originally began investigating -
it's possible that we should just take one of the larger spaces instead,
since it seems it will now be the same price.

But it's possible that the other space won't be available to us at this
point, in which case we are still limited to 200 for the plenaries and
therefore there's no advantage to *not* having them on the first and last
days when fewer people are in attendance.

> > Mon, August 25:		Full day of talks. 18 slots.
> > Tue, August 26:		Full day of talks. 18 slots.
> > Wed, August 27:		Day trip
> > Thu, August 28:		Hack day. BOFs either side of lunch (6 slots).
> > Fri, August 29:		Hack day. BOFs either side of lunch (6 slots).
> > Sat, August 30:		Hack day. BOFs post brunch (3 slots).
> > Sun, August 31:		Last day of conference. Post brunch lightning
> > 			talks (1hr30?), closing plenary, done by 4pm.
> > 			Hacklabs open.
> > Mon, September 1:	Leaving day. No hacklabs, leave rooms by noon.

> ...And what I don't really feel comfortable here is with the lack of
> balance. If we have the rooms available, of course, people will
> request ad-hoc sessions, so I doubt we would _really_ use only 6
> slots. We would most probably use over 15, as history has shown when
> we have an empty room.

> Having the 18 slots on three rooms during Sun/Mon/Tue would put much
> more pressure not only on the video team (they would be covering three
> and not just two rooms), but on attendees. Having to choose among
> *all* of our selected talks over three days can lead to insatisfaction
> with the overall program.

I'm not sure I understand your position here.  Are you saying that it's
important to have only two tracks of "main" talks running in parallel, with
the third talk room used only for BoFs?

Frankly, I don't believe this makes much of a difference to whether people
will have schedule conflicts.  If anything, I believe it's more important to
attend BoFs in person, rather than the recorded talks that people can view
later (or, as history shows, from the hacklab with live streaming).

Looking back at the DC13 schedule, I see that I was confused about what was
done for videoing; I mistakenly believed that we had 3 rooms being filmed,
where it was actually only two + BoF room.  So you may be right that it's
logistically infeasible to run three tracks of talks in parallel.

In that case, what do you propose instead?  How many slots does the talks
team want for formal talks?  (Noting that one of the motivations for the
mixed hack/talk format that we proposed this year was a feeling that
DebConf has been too talk heavy, with not enough in-between time)

> It's not a strong opinion... but I'm not that thrilled with the
> proposed time. It might lead to many people just sticking around
> until Tuesday and then going, as there's nothing "interesting"
> programmed anymore.

Why is that a bad thing?  If someone believes that only the talks are
interesting, not the hacking/bofs, isn't it *better* if they only come for
the parts they care about?

I don't think this is going to be the response of our typical DebConf
attendee, however.  I think Debian contributors are going to appreciate the
expanded opportunity to hack together.

> And if we decided to sacrifice DebCamp this time, I don't think it should
> be made in prejudice of the conference time proper.  Yes, seven days of
> talks might be a bit too much, but a strict three day-three day separation
> is also harsh.  I'd do the differentiation softer, or alternate between
> the hack and talk days.

First, I don't agree that DebCamp has been "sacrificed".  As Moray has
commented repeatedly, the previous DebCamp format is an inefficient means of
achieving its stated goals, because we aren't holding people accountable to
work plans or making sure that only the volunteers who are needed for setup
are coming as "volunteers".  The format this year has been deliberately
designed to improve upon the status quo, with the explicit understanding
that people who are actually coming with a work plan can ask the DPL for a
sprint before DebConf.  (And I think it's a major regression that the DC15
team has reverted this by reintroducing DebCamp for next year.)

Second, this "seven days" vs. "three days" comparison is highly inaccurate. 
DebConf13 was 7 days only if you count the daytrip day; so in fact it was
really only 6 days, and DC12 was 5.5 (6 days, minus day trip, plus welcome
talk on arrival day / day "0").  The schedule Jonathan proposed is 3.5 days,
plus BoFs, plus closing plenary.  Yes, it's less than in previous years, but
it's also still quite a bit more than "3 days".

I don't object to some fine tuning to get the right balance between hack
time and talk time, but it should only be that - fine tuning.  We surely
should not be trying to raise this back up to 5.5 days of talks, for

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: