Thanks for this thread. Given that the university has said they can start
signing contracts for this in October, and October is only 3 days away, we
really want to get these dates finalized ASAP.
We probably also want to start having regular IRC meetings again. Monthly
frequency should probably be sufficient for now, right?
Clarifying something from Patty's original mail, the precise limits on the
venue are:
- August 21: earliest date that PSU can accomodate us at the venue
- August 22: earliest date that PSU can accomodate a full set of people in
the dorms
- September 1: latest date that PSU can accomodate people in the dorms
- $late_enough_to_be_irrelevant: latest date that PSU can accomodate us at
the venue
So this has several implications.
- The week of DebConf is the last week of August, 2014; the week before
that, Thursday is the earliest day we can be there, so DebConf will
definitely *not* be the third week in August.
- Likewise, there is not going to be a week-long DebCamp before DebConf.
This was already the plan of the local team, but venue availability
confirms it.
- The venue *does* have some availability for a few days before the target
week, so we need to decide if we think we want to make use of this, and
how.
On Fri, Sep 27, 2013 at 09:47:07PM +0200, martin f krafft wrote:
> also sprach Patty Langasek <harmoney@dodds.net> [2013.09.27.1928 +0200]:
> > Good morning, everyone!
> Good evening.
> > Right now, we know we have the dates 24 Aug - 30 Aug, with
> > departure of no later than 1 September 2014 for our official
> > venue.
> Traditionally, the conference starts Sunday morning (24 Aug) and
> ends Saturday night (30 Aug), with departure on Sunday (31 Aug).
Traditionally, DebConf is also preceded by DebCamp. Since we aren't going
to have a DebCamp, I don't think we should be bound by tradition in other
aspects of the schedule.
(Also, I'm not sure how true it is that this is "tradition" - it certainly
seems to me that the DebConf schedule is inconsistent from year to year.)
> I'd think this is wise specifically due to Labor (Mon)Day, which will make
> travel a hassle and expensive too.
Labor Day is not a major air travel event in the US. I don't believe that
this will have any impact on anyone who books their travel a reasonable
amount of time in advance. The entire conference falls in high season for
the airlines; the impact of Labor Day itself should be negligible.
> > 2. DebCamp - yes or no? We do not have official venue (talk rooms)
> > for the week prior to our reserved dates (or the week after).
> > If we do have DebCamp, it will need to be restricted in number
> > and time (it won't be a week long).
> I think we should stick with DebCamp and we should try as hard as
> possible to make it as long as possible.
> We do not need talk rooms for that, but we do need hack space for 80
> people or thereabouts (with whiteboards ideally). And accomodation
> and food.
> > 3. Separate Hacking Time - yes or no? One thing the organizers
> > would like to see is hacking and collaborating time (different
> > from DebCamp) that doesn't conflict with the Talks Schedule.
> Isn't that what starts at 18:00 every day?
> But see below: especially with three talk tracks and maybe
> a schedule that runs until 19:00, make 12:00–16:00 be
> lunch+collaboration time.
So the driving factor for the above two discussion points is that I dislike
the DebCamp / DebConf split and always have. Americans by and large don't
have the vacation time to take for a two-week event like this, and even
though I'm fortunate enough to have an employer who will send me to DebConf
for work, even for me two weeks is too much. And I don't want to be
responsible for organizing an event that I myself would not be interested in
attending.
This is not to say that I think we should have only talks at DebConf. Quite
to the contrary, I think collaborative hacking is an important part of the
DebConf experience - I just think the temporal partitioning of DebCamp vs.
DebConf is misguided. I also don't think that DebCamp has been fulfilling
its stated purpose, lately: originally, this was conceived as a way to
support teams in hacking collaboratively, but it's largely been replaced by
team sprints in recent years: the workplans submitted for sponsorship to the
most recent DebCamp included mostly solo projects, not teams getting
together to work. I don't think DebCamp, as it currently exists, is the
optimal use of our sponsors money - and I know there are others on the team
who agree.
So I believe it's time for us to rethink DebCamp, by taking this back to
first principles and implementing something that maximizes the benefit to
Debian within the constraints that we have. From my perspective, the
purpose of DebConf + DebCamp taken as a whole is to provide a healthy
mixture of presentations about current/ongoing work in the project, social
interactions / opportunistic discussions ("hallway track"), and Debian
development work. Do others agree with that formulation?
I think to support Debian development work as part of the DebConf/DebCamp
complex does require *some* explicit separation between talks & development.
We already have that during DebConf week in the form of hacklabs, but that's
only spatial separation; we tend to fill the time of DebConf with as many
talks as we can, which means that there's no temporal separation, and folks
who are keen to attend talks can easily find themselves with no actual hack
time.
So I think we want explicit "hack-only" time when we don't schedule any
talks, rather than trying to fill all available times. As a strawman, I
would propose the following schedule:
- Fri, August 22 - Arrival day. People can check into the dorms after
noon. No talks; hacklabs open (maybe just one hacklab).
- Sat, August 23 - First day of the conference. No talks in the morning;
welcome talk in the midafternoon; talks may be scheduled in the evening
but only on a single track.
- Sun, August 24 - Full day of talks.
- Mon, August 25 - Talks in morning only. Afternoon/evening blocked for
hack time (and social events? - C&W)
- Tue, August 26 - Full day of talks.
- Wed, August 27 - Day Trip.
- Thu, August 28 - Talks in the afternoon only. Morning and evening
blocked for hack time. (Ok, let's be realistic, morning blocked for
sleeping in after hacking all night the night before...)
- Fri, August 29 - Full day of talks.
- Sat, August 30 - Full day of talks ?
- Sun, August 31 - Hack day / departure day. Hacklabs open, no talks
scheduled (except the closing talk?), people will start heading home.
- Mon, September 1 - End of conference. Hacklabs not open, and we kick you
out of the rooms at noon. ;)
I think this preserves many of the best features of past schedules, while
bringing a few new ones of its own. It gives us at least 4 days-worth of
talks on the schedule (maybe 5, depending on what people think we should do
Aug 30), as well as explicit space in the schedule for hacking, and it
staggers the hack time so that even folks not able to attend the entire
event can get a decent mix of both hacking and talks. And this keeps us
safely within the date range that PSU has set us, so we don't have to worry
about not being able to house people who show up.
Does this seem like a workable plan? Do people agree with the broad
strokes? We can discuss the details at length, but we at least need to
start getting our dates locked down so that we can move ahead with the
university.
FWIW, with the above schedule I think we would represent the DebConf dates
in public communications as being Aug 23-Aug 31 (with clarifications
everywhere appropriate).
Thanks,
--
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