From: Takashi Iwai <tiwai@suse.de>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
David Henningsson <david.henningsson@canonical.com>
Subject: Re: Plumbers: Please split audio topics into separate sessions
Date: Tue, 07 Aug 2012 07:58:40 +0200 [thread overview]
Message-ID: <s5htxwfi6pb.wl%tiwai@suse.de> (raw)
In-Reply-To: <20120806222417.GF26698@opensource.wolfsonmicro.com>
At Mon, 6 Aug 2012 23:24:17 +0100,
Mark Brown wrote:
>
> On Mon, Aug 06, 2012 at 10:11:44PM +0200, David Henningsson wrote:
> > On 08/06/2012 09:29 PM, Takashi Iwai wrote:
>
> >> Well, as already announced, each topic was planned to be about 20
> >> minutes, so I don't think we need to extend session time.
>
> > Judging from our last experience, where we had a two-hour session on
> > Sunday and then had to reschedule on Wednesday for two more hours, and
> > yet had to cancel the topic I was about to introduce, because everybody
> > was tired (and waiting for lunch), I certainly beg to differ!
>
> Hrm? Was this Plumbers or the BoF in Prague last year?
>
> >> Of course, it's possible to ask more slots, if you are sure that one
> >> topic would need really 40 minutes discussions.
>
> > It's the discussions that take time.
>
> On the other hand if we don't have much concrete to discuss then it can
> end up being too long.
>
> I guess this is one of the concerns I have with having lots of sessions
> - it means we've split topics up and have less play to manage time
> overall, it means we either cover less or take more time. The
> flexibility for attendees is good, though - have to see how the
> tradeoffs work.
My initial idea is to kick off discussions in the sessions, then
continue at BoF or whatever if not finished in time. This is often
more fruitful than too lengthy discussions. You can cool down and
reconsider the idea.
> > Also all of the 45 minutes is not effective discussion/presentation
> > time: Assume that we first wait 5 minutes for all people to appear, then
> > we have 5 minutes presentation and 15 - 20 minutes discussion for the
> > first topic, then 5 minutes are spent fiddling with the projector to
> > show the slides for the second topic...and suddenly there is just a few
> > minutes left for discussion of the second topic.
>
> This is a bit of a concern, yes.
Yeah, but we should apply a strict rule in such a case.
The preparation must be done before the session. If not, the topic
should be started without the video. Also, the topic is cut strictly
in time.
> > Also; we fly across half the world to get there, to spend just a few
> > minutes talking? Better have some margins. Maybe some session will end
> > early, but will it hurt? No. If we miss a topic, or have to cut it short
> > without a conclusion, will it hurt? Yes.
>
> Perhaps the best thing is to have an additional session for overrun
> rather than plan on everything being 45 minutes long?
As mentioned, we have already one additional slot, currently planned
for my channel-mapping API topic. I can shorten the topic and the
almost whole slot can be used for other discussions.
And, if needed, we can ask for a slot/room for BoF beforehand in
addition.
Takashi
next prev parent reply other threads:[~2012-08-07 5:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-06 19:09 Plumbers: Please split audio topics into separate sessions David Henningsson
2012-08-06 19:29 ` Takashi Iwai
2012-08-06 20:11 ` David Henningsson
2012-08-06 22:24 ` Mark Brown
2012-08-07 5:58 ` Takashi Iwai [this message]
2012-08-07 6:28 ` Vinod Koul
2012-08-07 6:41 ` David Henningsson
2012-08-07 7:11 ` Takashi Iwai
2012-08-07 8:08 ` David Henningsson
2012-08-07 8:35 ` Takashi Iwai
2012-08-07 11:19 ` David Henningsson
2012-08-07 11:15 ` Mark Brown
2012-08-07 11:26 ` David Henningsson
2012-08-07 13:57 ` Mark Brown
2012-08-07 14:04 ` Takashi Iwai
2012-08-07 14:06 ` Mark Brown
2012-08-06 19:38 ` Mark Brown
2012-08-06 20:14 ` David Henningsson
2012-08-06 21:45 ` Mark Brown
2012-08-07 6:42 ` Vinod Koul
2012-08-07 7:14 ` Takashi Iwai
2012-08-07 14:07 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5htxwfi6pb.wl%tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=david.henningsson@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.