Return-Path: 
 <dev-return-2244-apmail-community-dev-archive=community.apache.org@community.apache.org>
X-Original-To: apmail-community-dev-archive@minotaur.apache.org
Delivered-To: apmail-community-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 3100710725
	for <apmail-community-dev-archive@minotaur.apache.org>;
 Sun,  2 Feb 2014 14:11:54 +0000 (UTC)
Received: (qmail 29059 invoked by uid 500); 2 Feb 2014 14:11:49 -0000
Delivered-To: apmail-community-dev-archive@community.apache.org
Received: (qmail 28774 invoked by uid 500); 2 Feb 2014 14:11:44 -0000
Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@community.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@community.apache.org>
List-Post: <mailto:dev@community.apache.org>
List-Id: <dev.community.apache.org>
Reply-To: dev@community.apache.org
Delivered-To: mailing list dev@community.apache.org
Received: (qmail 28762 invoked by uid 99); 2 Feb 2014 14:11:44 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Feb 2014 14:11:43 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Received: from [209.85.160.46] (HELO mail-pb0-f46.google.com) (209.85.160.46)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Feb 2014 14:11:38 +0000
Received: by mail-pb0-f46.google.com with SMTP id um1so6068611pbc.5
        for <dev@community.apache.org>; Sun, 02 Feb 2014 06:11:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
         :cc:subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        bh=Zdc3quExHz7kGzVJ0UWXgek64Vyk48QtiHLSY8G9kfY=;
        b=ar+O+lxhMyoY1y94aVGXIJY278msutioJJgMk5My2LyOVpl4ziN78eMkciURwIy8hz
         dTktmhqrfcv7IHMHJHt/0pz4oBFciYeiJsVR1j6G/6aAy8BumWi39Ws0OLm+5g7j35u1
         ZWiPsspsaMcJj0mqayJ+UBsxvnLR32Msi+QVEL84wh4qSP81v/k8XmrQa7CbQnIp3Gv1
         0hiTHHmeqLVCOE0XQP5RaokRmTeurxmfOprbwZV/vLqg/r6L04ZRlYhIxRYdX8y37Zw/
         xFvHaVyHTW54A4Rm/vfq2nWIVd9quvja159+plRYvvjLxxzDRyUz3/An/JYtAeQV1aCM
         dqEw==
X-Gm-Message-State: 
 ALoCoQm7VyRDrUZn0Vu18u4nxpptSioRN1aKf1iYBFr2b+/fOKtVW+w7Wtj6Ta+GLz3LHDxaKjAW
X-Received: by 10.66.65.134 with SMTP id x6mr31427453pas.12.1391350276851;
        Sun, 02 Feb 2014 06:11:16 -0800 (PST)
Received: from localhost.localdomain
 ([2001:67c:1810:f054:3ea9:f4ff:fe17:87dc])
        by mx.google.com with ESMTPSA id
 id1sm46694056pbc.11.2014.02.02.06.11.14
        for <multiple recipients>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Sun, 02 Feb 2014 06:11:15 -0800 (PST)
Message-ID: <52EE51FE.3090300@rcbowen.com>
Date: Sun, 02 Feb 2014 15:11:10 +0100
From: Rich Bowen <rbowen@rcbowen.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Nick Burch <nick@apache.org>
CC: "dev@community.apache.org" <dev@community.apache.org>
Subject: Re: Fast Feather
References: <52EE3A75.6000307@rcbowen.com>
 <alpine.DEB.2.02.1402021232510.31868@urchin.earth.li>
In-Reply-To: <alpine.DEB.2.02.1402021232510.31868@urchin.earth.li>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org


On 02/02/2014 01:41 PM, Nick Burch wrote:
> On Sun, 2 Feb 2014, Rich Bowen wrote:
>> Nick, can you tell me how you envision the Fast Feather track 
>> working, from a scheduling perspective?
>>
>> ie, do we just give you a day-long slot and say "go for it", or is 
>> there more that we need to do on the scheduling side to accept 
>> specific talks for that track? Also, is it a day, or two days - what 
>> do you think you can fill?
>
> In the past, it has typically been a half day, or two quarter days. We 
> have also done a few lunchtime sessions, which work well for more 
> experienced speakers talking on something new+quick. Newer presenters 
> are best off in a small + cozy + friendly space though!
>
> Typically, we've opened submissions fairly close to the event, I've 
> picked half the talks a week out, then fill in the rest of the gaps 
> with last minute ideas (barcamps and hackathons are often good for 
> identifying these). FFT always causes a headache for the organisers, 
> as we need a schedule printing for the room + website updating much 
> much later than they generally like...
>
> Given the compressed timescales this time, one thing that might be 
> good is to open submissions when speaker notifications go out. That 
> way, anyone who has submitted for the first time and not been accepted 
> for a full slot can be suggested to submit for a 20 minute FFT one. 
> I've spotted a few talks when reviewing which I felt were "good idea, 
> not enough experience", so the FFT could be a good way to help these 
> speakers for next time. When submissions are open, we then get others 
> to submit too, especially the incubator, as the incubator has lots of 
> interesting things from people who are new to speaking.
>
> A whole day can be hard to fill, one afternoon or two half-afternoons 
> tends to be easier to get talks for + keep people interested. 
> Afternoons generally seem to work better than mornings. A few 
> lunchtime slots might be good too, maybe one day do (serious) 
> lightning talks at lunch, and another do some slightly longer FFT 
> ones? Depends on floor layouts though

Awesome. This helps. I'll try to slot it in in one of those ways, and 
run it by you before we go to print.

Thanks.


-- 
Rich Bowen - rbowen@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon