Xen devel - Aug 2013 - [Seeking input] Format of Xen Project Developer Summit in October

Hi all,

last year, we had two parallel tracks at the Developer Summit : some 
felt, this was positive - others felt, we should go back to a single 
track. Also, the discussion sessions at this year''s Hackathon were very
effective and popular. We are also having our first User Summit in 
September: so I expect that there will be less user content at the 
Developer Summit.

I have booked two rooms for the Xen Developer summit, which means we 
have a number of options:
Option 1) We could run two parallel content tracks for most of the event 
(assuming we have enough content)
Option 2) We could use the second room for in-depth discussions (using 
an unconference scheduling mechanism as we have done at the Hackathon: 
if you want to know how this works do read 
http://blog.xen.org/index.php/2013/05/28/event-report-xen-hackathon-2013/ - 
we would use a simplified version of the mechanism described). These 
would run in parallel to the main program, for example in the afternoon. 
In other words, we would have "BoF type meetings decided on the day"
or
"hacking sessions" or "get started with X" or "how do
we solve problem
Z" etc. that would happen in the second room in parallel to talks.
Option 3) A mixture of both

Please let me know your views by voting in public. Example "+1 for 
option 3", "+1 for option 1", ...

Regards
Lars

>>> On 08.08.13 at 13:39, Lars Kurth <lars.kurth@xen.org> wrote:
> Option 1) We could run two parallel content tracks for most of the event 
> (assuming we have enough content)
-1
> Option 2) We could use the second room for in-depth discussions (using 
> an unconference scheduling mechanism as we have done at the Hackathon: 
> if you want to know how this works do read 
> http://blog.xen.org/index.php/2013/05/28/event-report-xen-hackathon-2013/ -
> we would use a simplified version of the mechanism described). These 
> would run in parallel to the main program, for example in the afternoon. 
> In other words, we would have "BoF type meetings decided on the
day" or
> "hacking sessions" or "get started with X" or "how
do we solve problem
> Z" etc. that would happen in the second room in parallel to talks.
+1
> Option 3) A mixture of both
0

Jan

On Thu, 2013-08-08 at 12:39 +0100, Lars Kurth wrote:
> Hi all,
> 
> last year, we had two parallel tracks at the Developer Summit : some 
> felt, this was positive - others felt, we should go back to a single 
> track. Also, the discussion sessions at this year''s Hackathon were
very
> effective and popular. We are also having our first User Summit in 
> September: so I expect that there will be less user content at the 
> Developer Summit.
> 
> I have booked two rooms for the Xen Developer summit, which means we 
> have a number of options:
> Option 1) We could run two parallel content tracks for most of the event 
> (assuming we have enough content)
> Option 2) We could use the second room for in-depth discussions (using 
> an unconference scheduling mechanism as we have done at the Hackathon: 
> if you want to know how this works do read 
> http://blog.xen.org/index.php/2013/05/28/event-report-xen-hackathon-2013/ -
> we would use a simplified version of the mechanism described). These 
> would run in parallel to the main program, for example in the afternoon. 
> In other words, we would have "BoF type meetings decided on the
day" or
> "hacking sessions" or "get started with X" or "how
do we solve problem
> Z" etc. that would happen in the second room in parallel to talks.
> Option 3) A mixture of both
> 
> Please let me know your views by voting in public. Example "+1 for 
> option 3", "+1 for option 1", ...
No particularly strong preference,  but leaning more towards #2.

Ian.

On Thu, Aug 08, 2013 at 12:46:58PM +0100, Jan Beulich
wrote:
> >>> On 08.08.13 at 13:39, Lars Kurth <lars.kurth@xen.org>
wrote:
> > Option 1) We could run two parallel content tracks for most of the
event
> > (assuming we have enough content)
> 
> -1
-1
> 
> > Option 2) We could use the second room for in-depth discussions (using
> > an unconference scheduling mechanism as we have done at the Hackathon:
> > if you want to know how this works do read 
> >
http://blog.xen.org/index.php/2013/05/28/event-report-xen-hackathon-2013/ -
> > we would use a simplified version of the mechanism described). These 
> > would run in parallel to the main program, for example in the
afternoon.
> > In other words, we would have "BoF type meetings decided on the
day" or
> > "hacking sessions" or "get started with X" or
"how do we solve problem
> > Z" etc. that would happen in the second room in parallel to
talks.
> 
> +1
+1
> 
> > Option 3) A mixture of both
> 
> 0
-1
> 
> Jan
I concur with Jan. There is already so much going on that week with LKS
and LinuxCon, XenSummit, and meeting other people in the halls - that
having everybody in one room would make it much easier to have discussions.

Instead of trying to find some "time" to talk to them and potentially
not
having enough people in the discussion.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

On gio, 2013-08-08 at 15:20 -0400, Konrad Rzeszutek Wilk
wrote:
> > > Option 2) We could use the second room for in-depth discussions
(using
> > > an unconference scheduling mechanism as we have done at the
Hackathon:
> > > if you want to know how this works do read 
> > >
http://blog.xen.org/index.php/2013/05/28/event-report-xen-hackathon-2013/ -
> > > we would use a simplified version of the mechanism described).
These
> > > would run in parallel to the main program, for example in the
afternoon.
> > > In other words, we would have "BoF type meetings decided on
the day" or
> > > "hacking sessions" or "get started with X" or
"how do we solve problem
> > > Z" etc. that would happen in the second room in parallel to
talks.
> > 
> +1
> 
> I concur with Jan. There is already so much going on that week with LKS
> and LinuxCon, XenSummit, and meeting other people in the halls - that
> having everybody in one room would make it much easier to have discussions.
>
> Instead of trying to find some "time" to talk to them and
potentially not
> having enough people in the discussion.
> 
I tend to agree, especially since I liked the hackathon format and
outcome. However, one concern I have with 2) is, who''s been listening
to
the talks from the main program in RoomA, if everyone is in RoomB having
"fun" discussions?

Wouldn''t that raise fairness issues regarding which talks are scheduled
to happen in parallel with the BoF sessions, as compared to the ones
that are not?

As I said, I liked it for the hackathon but that was, well, the
hackathon... In this case I fear it could be a bit both rude and
pointless to ask people to submit talks for the summit and then have
noone listening to the presentations, because everyone is in the room
next door! :-O

Or did I misunderstand something and there is no risk of that?

Also, won''t the "let''s have everyone in one room" be
covered by the
Devs/Committers/Maintainers Meeting, of course, if we have one?

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

> Wouldn''t that raise fairness issues regarding which talks are
scheduled
> to happen in parallel with the BoF sessions, as compared to the ones
> that are not?
I am not convinced it would. If there was one BoF discussion going on in
parallel to the track in the afternoon, I wouldn''t expect that more
than a
dozen or so people would come to a specific discussion. It''ll create a
degree of competition with the main program, but that would exist also if
we had two tracks. We had around 100-150 people attend the summit in the
past. Am not convinced this will be a big issue. The alternative is to just
set up the second room as hacker space and as a space for
"in-corridor"
meetings and have no tool to schedule.
> Also, won''t the "let''s have everyone in one
room" be covered by the
> Devs/Committers/Maintainers Meeting, of course, if we have one
Yes, but I expect that 1/2 wont be enough and that there are bound to be
follow-up discussions, which need maybe a few core devs.

Lars


On Fri, Aug 9, 2013 at 11:49 AM, Dario Faggioli
<dario.faggioli@citrix.com>wrote:
> On gio, 2013-08-08 at 15:20 -0400, Konrad Rzeszutek Wilk wrote:
> > > > Option 2) We could use the second room for in-depth
discussions
> (using
> > > > an unconference scheduling mechanism as we have done at the
> Hackathon:
> > > > if you want to know how this works do read
> > > >
> http://blog.xen.org/index.php/2013/05/28/event-report-xen-hackathon-2013/-
> > > > we would use a simplified version of the mechanism
described). These
> > > > would run in parallel to the main program, for example in
the
> afternoon.
> > > > In other words, we would have "BoF type meetings
decided on the day"
> or
> > > > "hacking sessions" or "get started with
X" or "how do we solve
> problem
> > > > Z" etc. that would happen in the second room in
parallel to talks.
> > >
> > +1
> >
> > I concur with Jan. There is already so much going on that week with
LKS
> > and LinuxCon, XenSummit, and meeting other people in the halls - that
> > having everybody in one room would make it much easier to have
> discussions.
> >
> > Instead of trying to find some "time" to talk to them and
potentially not
> > having enough people in the discussion.
> >
> I tend to agree, especially since I liked the hackathon format and
> outcome. However, one concern I have with 2) is, who''s been
listening to
> the talks from the main program in RoomA, if everyone is in RoomB having
> "fun" discussions?
>
> Wouldn''t that raise fairness issues regarding which talks are
scheduled
> to happen in parallel with the BoF sessions, as compared to the ones
> that are not?
>
> As I said, I liked it for the hackathon but that was, well, the
> hackathon... In this case I fear it could be a bit both rude and
> pointless to ask people to submit talks for the summit and then have
> noone listening to the presentations, because everyone is in the room
> next door! :-O
>
> Or did I misunderstand something and there is no risk of that?
>
> Also, won''t the "let''s have everyone in one
room" be covered by the
> Devs/Committers/Maintainers Meeting, of course, if we have one?
>
> Thanks and Regards,
> Dario
>
> --
> <<This happens because I choose it to happen!>> (Raistlin
Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

> I concur with Jan. There is already so much going on that week with LKS
> and LinuxCon, XenSummit, and meeting other people in the halls - that
> having everybody in one room would make it much easier to have
discussions.
The only thing we will be competing with during XenSummit is LKS (which
affects you and Stefano mainly) and ourselves. Automotive Linux Summit and
ELCE (Embedded Linux Conf) is on, but the majority of us don''t really
have
conflicts with these.

KVM Forum has a harder time this year, overlapping with LC and CloudOpen.

The Dev Meeting will be a little harder, but on Wed afternoon all the other
events will start to frizzle out (with the exception of LKS which starts on
the Wed). If there are concerns, we could get a space later in the
afternoon and order warm food and beer at the Dev Meeting (instead of
coffee and snacks).

Lars


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

On ven, 2013-08-09 at 14:17 +0100, Lars Kurth wrote:
> > Wouldn''t that raise fairness issues regarding which talks are
> scheduled
> > to happen in parallel with the BoF sessions, as compared to the ones
> > that are not?
> I am not convinced it would. 
>
Fair enough. :-) BTW, there might be a quite fundamental
misunderstanding here. Are you talking about _one_ BoF discussion at a
time in the "other room" --as you say below-- or _several_ of them at
the same time, still in the "other room", involving different group of
people --as it was at the Hackathon?

It might sound subtle, and it probably is, but I think it does make a
difference (see below).
> If there was one BoF discussion going on in parallel to the track in
> the afternoon, I wouldn''t expect that more than a dozen or so
people
> would come to a specific discussion. 
>
Yes, I think that too.
> It''ll create a degree of competition with the main program, but
that
> would exist also if we had two tracks. 
>
Well, it is indeed the same  as having two tracks if we have, at any
given time, *1* thing going on in room A (e.g., main talks track) and
*1* thing going on in room B (e.g., one specific BoF/hacking session).
In this case, I agree with you, and most of my concerns would just
disappear.

OTOH, if there''s a talk in room A and (even if just potentially), 10
BoFs in room B (it was like this at the Hackathon), then it looks like a
way less fair competition to me. :-/

So, sorry if it''s my fault not understanding this from the beginning,
which one are we talking about?
> The alternative is to just set up the second room as hacker space and
> as a space for "in-corridor" meetings and have no tool to
schedule.
> 
Well, sure, you can''t force people to stay in a room listening to a
talk, if the talk it''s not interesting for them, and any attempt to do
that will fail miserably, I concur with that, and I''m not asking for
anything like this! :-P

Nevertheless, having visited quite some conferences during the past
ages, I think the format is important (as this thread testifies), and I
think we at least should be really careful in making it clear how it
will be like, especially when we ask people to submit their talks and
come to Scotland to give the presentation, if accepted.

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

> OTOH, if there''s a talk in room A and (even if just potentially),
10
> BoFs in room B (it was like this at the Hackathon), then it looks like a
> way less fair competition to me. :-/
I was thinking of ONE BoF in the other room


On Fri, Aug 9, 2013 at 2:49 PM, Dario Faggioli
<dario.faggioli@citrix.com>wrote:
> On ven, 2013-08-09 at 14:17 +0100, Lars Kurth wrote:
> > > Wouldn''t that raise fairness issues regarding which
talks are
> > scheduled
> > > to happen in parallel with the BoF sessions, as compared to the
ones
> > > that are not?
> > I am not convinced it would.
> >
> Fair enough. :-) BTW, there might be a quite fundamental
> misunderstanding here. Are you talking about _one_ BoF discussion at a
> time in the "other room" --as you say below-- or _several_ of
them at
> the same time, still in the "other room", involving different
group of
> people --as it was at the Hackathon?
>
> It might sound subtle, and it probably is, but I think it does make a
> difference (see below).
>
> > If there was one BoF discussion going on in parallel to the track in
> > the afternoon, I wouldn''t expect that more than a dozen or so
people
> > would come to a specific discussion.
> >
> Yes, I think that too.
>
> > It''ll create a degree of competition with the main program,
but that
> > would exist also if we had two tracks.
> >
> Well, it is indeed the same  as having two tracks if we have, at any
> given time, *1* thing going on in room A (e.g., main talks track) and
> *1* thing going on in room B (e.g., one specific BoF/hacking session).
> In this case, I agree with you, and most of my concerns would just
> disappear.
>
> OTOH, if there''s a talk in room A and (even if just potentially),
10
> BoFs in room B (it was like this at the Hackathon), then it looks like a
> way less fair competition to me. :-/
>
> So, sorry if it''s my fault not understanding this from the
beginning,
> which one are we talking about?
>
> > The alternative is to just set up the second room as hacker space and
> > as a space for "in-corridor" meetings and have no tool to
schedule.
> >
> Well, sure, you can''t force people to stay in a room listening to
a
> talk, if the talk it''s not interesting for them, and any attempt
to do
> that will fail miserably, I concur with that, and I''m not asking
for
> anything like this! :-P
>
> Nevertheless, having visited quite some conferences during the past
> ages, I think the format is important (as this thread testifies), and I
> think we at least should be really careful in making it clear how it
> will be like, especially when we ask people to submit their talks and
> come to Scotland to give the presentation, if accepted.
>
> Regards,
> Dario
>
> --
> <<This happens because I choose it to happen!>> (Raistlin
Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

On ven, 2013-08-09 at 14:59 +0100, Lars Kurth wrote:
> > OTOH, if there''s a talk in room A and (even if just
potentially), 10
> > BoFs in room B (it was like this at the Hackathon), then it looks
> like a
> > way less fair competition to me. :-/
> I was thinking of ONE BoF in the other room
> 
Ok, I see.

Personally, I haven''t made up my mind about what the best option would
be yet (and I will vote accordingly as soon as that will happen), but at
least, with this clarification, the concerns I had about option 2 went
away.

Thanks for clarifying that. :-)
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel