Eoghan Glynn wrote:
Am I missing some compelling advantage of moving all these emergent
project-specific meetups to the Friday?
One is that due to space limitations, we won't have nearly as many
pods as in Atlanta (more like half or a third of them). Without one
pod per program, the model breaks a bit.
A-ha, OK.
Will the subset of projects allocated a pod be fixed, or will the
pod space float between projects as the week progresses?
(for example, it's unlikely that a project will be using its pod
space when its design session track is in-progress, so the pod could
be passed on to another project)
We'll have to design some novel pod-switching algorithm, but I kinda
want to know how many pods we can have before we start designing. I'm
visiting the space again on Monday.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
Apologies for jumping on this thread late.
I'm all for the idea of accommodating a more fluid form of project-
specific discussion, with the schedule emerging in a dynamic way.
But one aspect of the proposed summit redesign that isn't fully clear
to me is the cross-over between the new Contributors meetups and the
Project pods that we tried out for the first time in Atlanta.
That seemed, to me at least, to be a very useful experiment. In fact:
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda
sounds like quite a good description of how some projects used their
pods in ATL.
The advantage of the pods approach in my mind, included:
* no requirement for reducing the number of design sessions slots,
as the pod time ran in parallel with the design session tracks
of other projects
* depending on where in the week the project track occurred, the
pod time could include a chunk of scene-setting/preparation
discussion *in advance of* the more structured design sessions
* on a related theme, the pods did not rely on the graveyard shift
at the backend of the summit when folks tend to hit their Friday
afternoon brain-full state
Am I missing some compelling advantage of moving all these emergent
project-specific meetups to the Friday?
Cheers,
Eoghan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Eoghan Glynn wrote:
[...]
Am I missing some compelling advantage of moving all these emergent
project-specific meetups to the Friday?
One is that due to space limitations, we won't have nearly as many
pods as in Atlanta (more like half or a third of them). Without one
pod per program, the model breaks a bit.
The Friday setup also allows for more room (rather than a small
roundtable) since we can reuse regular rooms (and maybe split them up).
It appears on the schedule as a specific set of hours where contributors
on a given program gather, so it's easier to reach critical mass.
Finally for projects like Nova, which had regular sessions all the days.
I also like having them all on the last day so that you can react to
previous sessions and discuss useful stuff.
If that makes you feel more comfortable, you can think of it as a
pod-only day, with a bit more publicity, larger pods and where we use
all the summit space available for pods :)
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Am I missing some compelling advantage of moving all these emergent
project-specific meetups to the Friday?
One is that due to space limitations, we won't have nearly as many
pods as in Atlanta (more like half or a third of them). Without one
pod per program, the model breaks a bit.
A-ha, OK.
Will the subset of projects allocated a pod be fixed, or will the
pod space float between projects as the week progresses?
(for example, it's unlikely that a project will be using its pod
space when its design session track is in-progress, so the pod could
be passed on to another project)
Cheers,
Eoghan
The Friday setup also allows for more room (rather than a small
roundtable) since we can reuse regular rooms (and maybe split them up).
It appears on the schedule as a specific set of hours where contributors
on a given program gather, so it's easier to reach critical mass.
Finally for projects like Nova, which had regular sessions all the days.
I also like having them all on the last day so that you can react to
previous sessions and discuss useful stuff.
If that makes you feel more comfortable, you can think of it as a
pod-only day, with a bit more publicity, larger pods and where we use
all the summit space available for pods :)
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hayes, Graham wrote:
On Fri, 2014-08-29 at 17:56 +0200, Thierry Carrez wrote:
Hayes, Graham wrote:
Would the programs for those projects not get design summit time? I
thought the Programs got Design summit time, not projects... If not, can
the Programs get design summit time?
Sure, that's what Anne probably meant. Time for the program behind every
incubated project.
Sure,
I was referring to the the 2 main days - (days 2 and 3)
I thought that was a benefit of having a Program? The PTL chooses the
sessions, and the PTL is over a program, so I assumed that programs
would get both Pods and some design summit time (not 1/2 a day on the
Tuesday)
I know we (designate) got some great work done last year, but most of it
was in isolation, as we had one 40 min session, and one 1/2 day session,
but the rest of the sessions were unofficial ones, which meant that
people in the community who were not as engaged missed out on the
discussions.
Would there be space for programs with incubated projects at the
'Contributors meetups' ?
We have limited space in Paris, so there won't be pods for everyone like
in Atlanta. I'm still waiting for venue maps to see how we can make the
best use of the space we have.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On Fri, 2014-08-29 at 17:56 +0200, Thierry Carrez wrote:
Hayes, Graham wrote:
Yep, I think this works in theory, the tough part will be when all the
incubating projects realize they're sending people for a single day?
Maybe it'll work out differently than I think though. It means fitting
ironic, barbican, designate, manila, marconi in a day?
Actually those projects would get pod space for the rest of the week, so
they should stay! Also some of them might have graduated by then :)
Would the programs for those projects not get design summit time? I
thought the Programs got Design summit time, not projects... If not, can
the Programs get design summit time?
Sure, that's what Anne probably meant. Time for the program behind every
incubated project.
Sure,
I was referring to the the 2 main days - (days 2 and 3)
I thought that was a benefit of having a Program? The PTL chooses the
sessions, and the PTL is over a program, so I assumed that programs
would get both Pods and some design summit time (not 1/2 a day on the
Tuesday)
I know we (designate) got some great work done last year, but most of it
was in isolation, as we had one 40 min session, and one 1/2 day session,
but the rest of the sessions were unofficial ones, which meant that
people in the community who were not as engaged missed out on the
discussions.
Would there be space for programs with incubated projects at the
'Contributors meetups' ?
Thanks,
--
Graham
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Sean Dague wrote:
On 08/28/2014 03:06 PM, Jay Pipes wrote:
On 08/28/2014 02:21 PM, Sean Dague wrote:
On 08/28/2014 01:58 PM, Jay Pipes wrote:
On 08/27/2014 11:34 AM, Doug Hellmann wrote:
On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org
wrote:
Day 1. Cross-project sessions / incubated projects / other
projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the
various experiments we conducted during juno. Don't hesitate to
schedule 2 slots for discussions, so that we have time to come to
the bottom of those issues. Incubated projects (and maybe other
projects, if space allows) occupy the remaining space on day 1, and
could occupy pods on the other days.
If anything, I’d like to have fewer cross-project tracks running
simultaneously. Depending on which are proposed, maybe we can make
that happen. On the other hand, cross-project issues is a big theme
right now so maybe we should consider devoting more than a day to
dealing with them.
I agree with Doug here. I'd almost say having a single cross-project
room, with serialized content would be better than 3 separate
cross-project tracks. By nature, the cross-project sessions will attract
developers that work or are interested in a set of projects that looks
like a big Venn diagram. By having 3 separate cross-project tracks, we
would increase the likelihood that developers would once more have to
choose among simultaneous sessions that they have equal interest in. For
Infra and QA folks, this likelihood is even greater...
I think I'd prefer a single cross-project track on the first day.
So the fallout of that is there will be 6 or 7 cross-project slots for
the design summit. Maybe that's the right mix if the TC does a good job
picking the top 5 things we want accomplished from a cross project
standpoint during the cycle. But it's going to have to be a pretty
directed pick. I think last time we had 21 slots, and with a couple of
doubling up that gave 19 sessions. (about 30 - 35 proposals for that
slot set).
I'm not sure that would be a bad thing :)
I think one of the reasons the mid-cycles have been successful is that
they have adequately limited the scope of discussions and I think by
doing our homework by fully vetting and voting on cross-project sessions
and being OK with saying No, not this time., we will be more
productive than if we had 20+ cross-project sessions.
Just my two cents, though..
I'm not sure it would be a bad thing either. I just wanted to be
explicit about what we are saying the cross projects sessions are for in
this case: the 5 key cross project activities the TC believes should be
worked on this next cycle.
There is a trade-off here. Parallel cross-project tracks let us address
more issues in the limited time we have, and they also let us split the
audience so that we don't end up at 500 in the same room and nothing
gets done in 40min. It's true that sometimes you wish you could be in
two different places at the same time, but we generally prevent the most
blatant collisions during scheduling, and sometimes forcing people to
choose what they really care about is not that bad.
The feedback I got from Atlanta was that the 3-parallel-room setup went
well, and there weren't that many conflicts.
Maybe having *2* cross-project topics running at the same time (instead
of 3 or 1) would be the right trade-off. We would still need to be more
picky in selecting which issues we want to address, we would split the
audience into two rooms, and we would reduce the likelihood of conflict
significantly.
The other question is if we did that what's running in competition to
cross project day? Is it another free form pod day for people not
working on those things?
The 3 or 4 other rooms would give incubated projects (and other
projects) some scheduled time. It also runs at the same time as the
conference.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Anne Gentle wrote:
On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez thie...@openstack.org
mailto:thie...@openstack.org wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Yep, I think this works in theory, the tough part will be when all the
incubating projects realize they're sending people for a single day?
Maybe it'll work out differently than I think though. It means fitting
ironic, barbican, designate, manila, marconi in a day?
Actually those projects would get pod space for the rest of the week, so
they should stay! Also some of them might have graduated by then :)
Also since QA, Infra, and Docs are cross-project AND Programs, where do
they land?
I think those teams work on different issues. Some issues require a lot
of communication and input because they are cross-project problems that
those teams are tasked with solving -- in which case that belongs to the
cross-project day. Other issues are more implementation details and
require mostly the team members but not so much external input -- those
belong to the specific slots or the contributors meetup. Obviously
some things will be a bit borderline and we'll have to pick one or the
other based on available slots.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On Fri, 2014-08-29 at 11:23 +0200, Thierry Carrez wrote:
Anne Gentle wrote:
On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez thie...@openstack.org
mailto:thie...@openstack.org wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Yep, I think this works in theory, the tough part will be when all the
incubating projects realize they're sending people for a single day?
Maybe it'll work out differently than I think though. It means fitting
ironic, barbican, designate, manila, marconi in a day?
Actually those projects would get pod space for the rest of the week, so
they should stay! Also some of them might have graduated by then :)
Would the programs for those projects not get design summit time? I
thought the Programs got Design summit time, not projects... If not, can
the Programs get design summit time?
Also since QA, Infra, and Docs are cross-project AND Programs, where do
they land?
I think those teams work on different issues. Some issues require a lot
of communication and input because they are cross-project problems that
those teams are tasked with solving -- in which case that belongs to the
cross-project day. Other issues are more implementation details and
require mostly the team members but not so much external input -- those
belong to the specific slots or the contributors meetup. Obviously
some things will be a bit borderline and we'll have to pick one or the
other based on available slots.
signature.asc
Description: This is a digitally signed message part
smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hayes, Graham wrote:
Yep, I think this works in theory, the tough part will be when all the
incubating projects realize they're sending people for a single day?
Maybe it'll work out differently than I think though. It means fitting
ironic, barbican, designate, manila, marconi in a day?
Actually those projects would get pod space for the rest of the week, so
they should stay! Also some of them might have graduated by then :)
Would the programs for those projects not get design summit time? I
thought the Programs got Design summit time, not projects... If not, can
the Programs get design summit time?
Sure, that's what Anne probably meant. Time for the program behind every
incubated project.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On 08/27/2014 11:34 AM, Doug Hellmann wrote:
On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org
wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design
Summit format to make it more productive. I've heard the feedback
from the mid-cycle meetups and would like to apply some of those
ideas for Paris, within the constraints we have (already booked
space and time). Here is something we could do:
Day 1. Cross-project sessions / incubated projects / other
projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the
various experiments we conducted during juno. Don't hesitate to
schedule 2 slots for discussions, so that we have time to come to
the bottom of those issues. Incubated projects (and maybe other
projects, if space allows) occupy the remaining space on day 1, and
could occupy pods on the other days.
If anything, I’d like to have fewer cross-project tracks running
simultaneously. Depending on which are proposed, maybe we can make
that happen. On the other hand, cross-project issues is a big theme
right now so maybe we should consider devoting more than a day to
dealing with them.
I agree with Doug here. I'd almost say having a single cross-project
room, with serialized content would be better than 3 separate
cross-project tracks. By nature, the cross-project sessions will attract
developers that work or are interested in a set of projects that looks
like a big Venn diagram. By having 3 separate cross-project tracks, we
would increase the likelihood that developers would once more have to
choose among simultaneous sessions that they have equal interest in. For
Infra and QA folks, this likelihood is even greater...
I think I'd prefer a single cross-project track on the first day.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less
slots available. So, rather than trying to cover all the scope, the
idea would be to focus those sessions on specific issues which
really require face-to-face discussion (which can't be solved on
the ML or using spec discussion) *or* require a lot of user
feedback. That way, appearing in the general schedule is very
helpful. This will require us to be a lot stricter on what we
accept there and what we don't -- we won't have space for courtesy
sessions anymore, and traditional/unnecessary sessions (like my
traditional release schedule one) should just move to the
mailing-list.
The message I’m getting from this change in available space is that
we need to start thinking about and writing up ideas early, so teams
can figure out which upcoming specs need more discussion and which
don’t.
++
Also, I think as a community we need to get much better about saying
No for certain things. No to sessions that don't have much specific
details to them. No to blueprints that don't add much functionality that
cannot be widely used or taken advantage of. No to specs that don't have
a narrow-enough scope, etc.
I also think we need to be better at saying Yes to other things,
though... but that's a different thread ;)
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can
conduct parallel midcycle-meetup-like contributors gatherings, with
no time boundaries and an open agenda. Large projects could get a
full day, smaller projects would get half a day (but could continue
the discussion in a local bar). Ideally that meetup would end with
some alignment on release goals, but the idea is to make the best
of that time together to solve the issues you have. Friday would
finish with the design summit feedback session, for those who are
still around.
This is a good compromise between needing to allow folks to move
around between tracks (including speaking at the conference) and
having a large block of unstructured time for deep dives.
Agreed.
Best,
-jay
I think this proposal makes the best use of our setup: discuss
clear cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate
the success of midcycle meetup-like open unscheduled time to
discuss whatever is hot at this point.
There are still details to work out (is it possible split the
space, should we use the usual design summit CFP website to
organize the scheduled time...), but I would first like to have
your feedback on this format. Also if you have alternative
proposals that would make a better use of our 4 days, let me know.
Cheers,
-- Thierry Carrez (ttx)
___ OpenStack-dev
mailing list OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___ OpenStack-dev mailing
list OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On 08/28/2014 01:58 PM, Jay Pipes wrote:
On 08/27/2014 11:34 AM, Doug Hellmann wrote:
On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org
wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design
Summit format to make it more productive. I've heard the feedback
from the mid-cycle meetups and would like to apply some of those
ideas for Paris, within the constraints we have (already booked
space and time). Here is something we could do:
Day 1. Cross-project sessions / incubated projects / other
projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the
various experiments we conducted during juno. Don't hesitate to
schedule 2 slots for discussions, so that we have time to come to
the bottom of those issues. Incubated projects (and maybe other
projects, if space allows) occupy the remaining space on day 1, and
could occupy pods on the other days.
If anything, I’d like to have fewer cross-project tracks running
simultaneously. Depending on which are proposed, maybe we can make
that happen. On the other hand, cross-project issues is a big theme
right now so maybe we should consider devoting more than a day to
dealing with them.
I agree with Doug here. I'd almost say having a single cross-project
room, with serialized content would be better than 3 separate
cross-project tracks. By nature, the cross-project sessions will attract
developers that work or are interested in a set of projects that looks
like a big Venn diagram. By having 3 separate cross-project tracks, we
would increase the likelihood that developers would once more have to
choose among simultaneous sessions that they have equal interest in. For
Infra and QA folks, this likelihood is even greater...
I think I'd prefer a single cross-project track on the first day.
So the fallout of that is there will be 6 or 7 cross-project slots for
the design summit. Maybe that's the right mix if the TC does a good job
picking the top 5 things we want accomplished from a cross project
standpoint during the cycle. But it's going to have to be a pretty
directed pick. I think last time we had 21 slots, and with a couple of
doubling up that gave 19 sessions. (about 30 - 35 proposals for that
slot set).
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less
slots available. So, rather than trying to cover all the scope, the
idea would be to focus those sessions on specific issues which
really require face-to-face discussion (which can't be solved on
the ML or using spec discussion) *or* require a lot of user
feedback. That way, appearing in the general schedule is very
helpful. This will require us to be a lot stricter on what we
accept there and what we don't -- we won't have space for courtesy
sessions anymore, and traditional/unnecessary sessions (like my
traditional release schedule one) should just move to the
mailing-list.
The message I’m getting from this change in available space is that
we need to start thinking about and writing up ideas early, so teams
can figure out which upcoming specs need more discussion and which
don’t.
++
Also, I think as a community we need to get much better about saying
No for certain things. No to sessions that don't have much specific
details to them. No to blueprints that don't add much functionality that
cannot be widely used or taken advantage of. No to specs that don't have
a narrow-enough scope, etc.
I also think we need to be better at saying Yes to other things,
though... but that's a different thread ;)
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can
conduct parallel midcycle-meetup-like contributors gatherings, with
no time boundaries and an open agenda. Large projects could get a
full day, smaller projects would get half a day (but could continue
the discussion in a local bar). Ideally that meetup would end with
some alignment on release goals, but the idea is to make the best
of that time together to solve the issues you have. Friday would
finish with the design summit feedback session, for those who are
still around.
This is a good compromise between needing to allow folks to move
around between tracks (including speaking at the conference) and
having a large block of unstructured time for deep dives.
Agreed.
Best,
-jay
I think this proposal makes the best use of our setup: discuss
clear cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate
the success of midcycle meetup-like open unscheduled time to
discuss whatever is hot at this point.
There are still details to work out (is it possible split the
space, should we use the usual design summit CFP website to
organize the scheduled time...), but I would first like

On 08/28/2014 02:21 PM, Sean Dague wrote:
On 08/28/2014 01:58 PM, Jay Pipes wrote:
On 08/27/2014 11:34 AM, Doug Hellmann wrote:
On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org
wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design
Summit format to make it more productive. I've heard the feedback
from the mid-cycle meetups and would like to apply some of those
ideas for Paris, within the constraints we have (already booked
space and time). Here is something we could do:
Day 1. Cross-project sessions / incubated projects / other
projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the
various experiments we conducted during juno. Don't hesitate to
schedule 2 slots for discussions, so that we have time to come to
the bottom of those issues. Incubated projects (and maybe other
projects, if space allows) occupy the remaining space on day 1, and
could occupy pods on the other days.
If anything, I’d like to have fewer cross-project tracks running
simultaneously. Depending on which are proposed, maybe we can make
that happen. On the other hand, cross-project issues is a big theme
right now so maybe we should consider devoting more than a day to
dealing with them.
I agree with Doug here. I'd almost say having a single cross-project
room, with serialized content would be better than 3 separate
cross-project tracks. By nature, the cross-project sessions will attract
developers that work or are interested in a set of projects that looks
like a big Venn diagram. By having 3 separate cross-project tracks, we
would increase the likelihood that developers would once more have to
choose among simultaneous sessions that they have equal interest in. For
Infra and QA folks, this likelihood is even greater...
I think I'd prefer a single cross-project track on the first day.
So the fallout of that is there will be 6 or 7 cross-project slots for
the design summit. Maybe that's the right mix if the TC does a good job
picking the top 5 things we want accomplished from a cross project
standpoint during the cycle. But it's going to have to be a pretty
directed pick. I think last time we had 21 slots, and with a couple of
doubling up that gave 19 sessions. (about 30 - 35 proposals for that
slot set).
I'm not sure that would be a bad thing :)
I think one of the reasons the mid-cycles have been successful is that
they have adequately limited the scope of discussions and I think by
doing our homework by fully vetting and voting on cross-project sessions
and being OK with saying No, not this time., we will be more
productive than if we had 20+ cross-project sessions.
Just my two cents, though..
-jay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On 08/28/2014 03:06 PM, Jay Pipes wrote:
On 08/28/2014 02:21 PM, Sean Dague wrote:
On 08/28/2014 01:58 PM, Jay Pipes wrote:
On 08/27/2014 11:34 AM, Doug Hellmann wrote:
On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org
wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design
Summit format to make it more productive. I've heard the feedback
from the mid-cycle meetups and would like to apply some of those
ideas for Paris, within the constraints we have (already booked
space and time). Here is something we could do:
Day 1. Cross-project sessions / incubated projects / other
projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the
various experiments we conducted during juno. Don't hesitate to
schedule 2 slots for discussions, so that we have time to come to
the bottom of those issues. Incubated projects (and maybe other
projects, if space allows) occupy the remaining space on day 1, and
could occupy pods on the other days.
If anything, I’d like to have fewer cross-project tracks running
simultaneously. Depending on which are proposed, maybe we can make
that happen. On the other hand, cross-project issues is a big theme
right now so maybe we should consider devoting more than a day to
dealing with them.
I agree with Doug here. I'd almost say having a single cross-project
room, with serialized content would be better than 3 separate
cross-project tracks. By nature, the cross-project sessions will attract
developers that work or are interested in a set of projects that looks
like a big Venn diagram. By having 3 separate cross-project tracks, we
would increase the likelihood that developers would once more have to
choose among simultaneous sessions that they have equal interest in. For
Infra and QA folks, this likelihood is even greater...
I think I'd prefer a single cross-project track on the first day.
So the fallout of that is there will be 6 or 7 cross-project slots for
the design summit. Maybe that's the right mix if the TC does a good job
picking the top 5 things we want accomplished from a cross project
standpoint during the cycle. But it's going to have to be a pretty
directed pick. I think last time we had 21 slots, and with a couple of
doubling up that gave 19 sessions. (about 30 - 35 proposals for that
slot set).
I'm not sure that would be a bad thing :)
I think one of the reasons the mid-cycles have been successful is that
they have adequately limited the scope of discussions and I think by
doing our homework by fully vetting and voting on cross-project sessions
and being OK with saying No, not this time., we will be more
productive than if we had 20+ cross-project sessions.
Just my two cents, though..
I'm not sure it would be a bad thing either. I just wanted to be
explicit about what we are saying the cross projects sessions are for in
this case: the 5 key cross project activities the TC believes should be
worked on this next cycle.
The other question is if we did that what's running in competition to
cross project day? Is it another free form pod day for people not
working on those things?
-Sean
-jay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez thie...@openstack.org
wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Yep, I think this works in theory, the tough part will be when all the
incubating projects realize they're sending people for a single day? Maybe
it'll work out differently than I think though. It means fitting ironic,
barbican, designate, manila, marconi in a day?
Also since QA, Infra, and Docs are cross-project AND Programs, where do
they land?
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
I like thinking about what we can move to the mailing lists. Nice.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
Sounds good.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On 08/28/2014 03:31 PM, Sean Dague wrote:
On 08/28/2014 03:06 PM, Jay Pipes wrote:
On 08/28/2014 02:21 PM, Sean Dague wrote:
On 08/28/2014 01:58 PM, Jay Pipes wrote:
On 08/27/2014 11:34 AM, Doug Hellmann wrote:
On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org
wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design
Summit format to make it more productive. I've heard the feedback
from the mid-cycle meetups and would like to apply some of those
ideas for Paris, within the constraints we have (already booked
space and time). Here is something we could do:
Day 1. Cross-project sessions / incubated projects / other
projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the
various experiments we conducted during juno. Don't hesitate to
schedule 2 slots for discussions, so that we have time to come to
the bottom of those issues. Incubated projects (and maybe other
projects, if space allows) occupy the remaining space on day 1, and
could occupy pods on the other days.
If anything, I’d like to have fewer cross-project tracks running
simultaneously. Depending on which are proposed, maybe we can make
that happen. On the other hand, cross-project issues is a big theme
right now so maybe we should consider devoting more than a day to
dealing with them.
I agree with Doug here. I'd almost say having a single cross-project
room, with serialized content would be better than 3 separate
cross-project tracks. By nature, the cross-project sessions will attract
developers that work or are interested in a set of projects that looks
like a big Venn diagram. By having 3 separate cross-project tracks, we
would increase the likelihood that developers would once more have to
choose among simultaneous sessions that they have equal interest in. For
Infra and QA folks, this likelihood is even greater...
I think I'd prefer a single cross-project track on the first day.
So the fallout of that is there will be 6 or 7 cross-project slots for
the design summit. Maybe that's the right mix if the TC does a good job
picking the top 5 things we want accomplished from a cross project
standpoint during the cycle. But it's going to have to be a pretty
directed pick. I think last time we had 21 slots, and with a couple of
doubling up that gave 19 sessions. (about 30 - 35 proposals for that
slot set).
I'm not sure that would be a bad thing :)
I think one of the reasons the mid-cycles have been successful is that
they have adequately limited the scope of discussions and I think by
doing our homework by fully vetting and voting on cross-project sessions
and being OK with saying No, not this time., we will be more
productive than if we had 20+ cross-project sessions.
Just my two cents, though..
I'm not sure it would be a bad thing either. I just wanted to be
explicit about what we are saying the cross projects sessions are for in
this case: the 5 key cross project activities the TC believes should be
worked on this next cycle.
Yes.
The other question is if we did that what's running in competition to
cross project day? Is it another free form pod day for people not
working on those things?
It could be a pod day, sure. Or just an extended hallway session day... :)
-jay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On 08/28/2014 03:31 PM, Sean Dague wrote:
On 08/28/2014 03:06 PM, Jay Pipes wrote:
On 08/28/2014 02:21 PM, Sean Dague wrote:
On 08/28/2014 01:58 PM, Jay Pipes wrote:
On 08/27/2014 11:34 AM, Doug Hellmann wrote:
On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org
wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design
Summit format to make it more productive. I've heard the feedback
from the mid-cycle meetups and would like to apply some of those
ideas for Paris, within the constraints we have (already booked
space and time). Here is something we could do:
Day 1. Cross-project sessions / incubated projects / other
projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the
various experiments we conducted during juno. Don't hesitate to
schedule 2 slots for discussions, so that we have time to come to
the bottom of those issues. Incubated projects (and maybe other
projects, if space allows) occupy the remaining space on day 1, and
could occupy pods on the other days.
If anything, I’d like to have fewer cross-project tracks running
simultaneously. Depending on which are proposed, maybe we can make
that happen. On the other hand, cross-project issues is a big theme
right now so maybe we should consider devoting more than a day to
dealing with them.
I agree with Doug here. I'd almost say having a single cross-project
room, with serialized content would be better than 3 separate
cross-project tracks. By nature, the cross-project sessions will attract
developers that work or are interested in a set of projects that looks
like a big Venn diagram. By having 3 separate cross-project tracks, we
would increase the likelihood that developers would once more have to
choose among simultaneous sessions that they have equal interest in. For
Infra and QA folks, this likelihood is even greater...
I think I'd prefer a single cross-project track on the first day.
So the fallout of that is there will be 6 or 7 cross-project slots for
the design summit. Maybe that's the right mix if the TC does a good job
picking the top 5 things we want accomplished from a cross project
standpoint during the cycle. But it's going to have to be a pretty
directed pick. I think last time we had 21 slots, and with a couple of
doubling up that gave 19 sessions. (about 30 - 35 proposals for that
slot set).
I'm not sure that would be a bad thing :)
I think one of the reasons the mid-cycles have been successful is that
they have adequately limited the scope of discussions and I think by
doing our homework by fully vetting and voting on cross-project sessions
and being OK with saying No, not this time., we will be more
productive than if we had 20+ cross-project sessions.
Just my two cents, though..
I'm not sure it would be a bad thing either. I just wanted to be
explicit about what we are saying the cross projects sessions are for in
this case: the 5 key cross project activities the TC believes should be
worked on this next cycle.
The other question is if we did that what's running in competition to
cross project day? Is it another free form pod day for people not
working on those things?
-Sean
-jay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I'm curious to know how many people would be expected to be all in the
same room? And what percentage of these folks are participating in the
conversation and how many are audience?
One of the issues that seem to be universal in the identified discontent
area with summit sessions currently (which gets discussed after each of
the mid-cycles) is that 30 people talking in a room with an audience of
200 isn't very efficient. I wonder if this well intentioned direction
might end up with this result which many folks I talked to don't want.
The other issue that comes to mind for me is trying to allow everyone to
be included in the discussion while keeping it focusing and reducing the
side conversations. If folks are impatient to have their point (or off
topic joke) heard, they won't wait for a turn from whoever is chairing,
they will just start talking. This can create tension for the rest of
the folks who *are* patiently trying to wait their turn. I chaired a day
and a half of discussions at the qa/infra mid-cycle (the rest of the
time was code sprinting) and it was a real challenge in a room of 30
people with a full spectrum of contributor experience (at least one
person made their first contribution in Germany plus there were folks
who have been involved since the beginning) to keep everyone

On Aug 28, 2014, at 3:31 PM, Sean Dague s...@dague.net wrote:
On 08/28/2014 03:06 PM, Jay Pipes wrote:
On 08/28/2014 02:21 PM, Sean Dague wrote:
On 08/28/2014 01:58 PM, Jay Pipes wrote:
On 08/27/2014 11:34 AM, Doug Hellmann wrote:
On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org
wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design
Summit format to make it more productive. I've heard the feedback
from the mid-cycle meetups and would like to apply some of those
ideas for Paris, within the constraints we have (already booked
space and time). Here is something we could do:
Day 1. Cross-project sessions / incubated projects / other
projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the
various experiments we conducted during juno. Don't hesitate to
schedule 2 slots for discussions, so that we have time to come to
the bottom of those issues. Incubated projects (and maybe other
projects, if space allows) occupy the remaining space on day 1, and
could occupy pods on the other days.
If anything, I’d like to have fewer cross-project tracks running
simultaneously. Depending on which are proposed, maybe we can make
that happen. On the other hand, cross-project issues is a big theme
right now so maybe we should consider devoting more than a day to
dealing with them.
I agree with Doug here. I'd almost say having a single cross-project
room, with serialized content would be better than 3 separate
cross-project tracks. By nature, the cross-project sessions will attract
developers that work or are interested in a set of projects that looks
like a big Venn diagram. By having 3 separate cross-project tracks, we
would increase the likelihood that developers would once more have to
choose among simultaneous sessions that they have equal interest in. For
Infra and QA folks, this likelihood is even greater...
I think I'd prefer a single cross-project track on the first day.
So the fallout of that is there will be 6 or 7 cross-project slots for
the design summit. Maybe that's the right mix if the TC does a good job
picking the top 5 things we want accomplished from a cross project
standpoint during the cycle. But it's going to have to be a pretty
directed pick. I think last time we had 21 slots, and with a couple of
doubling up that gave 19 sessions. (about 30 - 35 proposals for that
slot set).
I'm not sure that would be a bad thing :)
I think one of the reasons the mid-cycles have been successful is that
they have adequately limited the scope of discussions and I think by
doing our homework by fully vetting and voting on cross-project sessions
and being OK with saying No, not this time., we will be more
productive than if we had 20+ cross-project sessions.
Just my two cents, though..
I'm not sure it would be a bad thing either. I just wanted to be
explicit about what we are saying the cross projects sessions are for in
this case: the 5 key cross project activities the TC believes should be
worked on this next cycle.
We’ve talked about several cross-project needs recently. Let’s start a list of
things we think we’re ready to make significant progress on during Kilo (not
just things we *need* to do, but things we think we *can* do *now*):
1. logging cleanup and standardization
The other question is if we did that what's running in competition to
cross project day? Is it another free form pod day for people not
working on those things?
That seems like a good use of time.
-Sean
-jay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On 08/27/2014 08:51 AM, Thierry Carrez wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
I would add Don't hesitate to schedule 2 slots ... to the description
for days 2 and 3, as well. I think the same point applies for
project-specific sessions. I don't think I've seen that used for
project sessions much, but I think it would help in some cases.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
+1 on the format. I think it sounds like a nice iteration on our setup
to try some new ideas.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On 08/27/2014 08:51 AM, Thierry Carrez wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
I definitely like this approach. I think it will be really interesting
to collect feedback from people about the value they got from days 2 3
vs. Day 4.
I also wonder if we should lose a slot from days 1 - 3 and expand the
hallway time. Hallway track is always pretty interesting, and honestly
at a lot of interesting ideas spring up. The 10 minute transitions often
seem to feel like you are rushing between places too quickly some times.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On Wed, Aug 27, 2014 at 02:51:55PM +0200, Thierry Carrez wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
+1, I think what you've proposed is a pretty attractive evolution of
our previous design summit formats. I figure it is safer trying such
an evolutionary approach for Paris, rather than trying to make too
much of a big bang revolution at one time.
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On 27/08/14 09:55, Thierry Carrez wrote:
Daniel P. Berrange wrote:
On Wed, Aug 27, 2014 at 02:51:55PM +0200, Thierry Carrez wrote:
[...]
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
+1, I think what you've proposed is a pretty attractive evolution of
our previous design summit formats. I figure it is safer trying such
an evolutionary approach for Paris, rather than trying to make too
much of a big bang revolution at one time.
We have too many fixed constraints at this time for a big bang anyway.
What I like in the format is that the nature of the 4th day can change
completely based on the result of the 3 previous days. If a major topic
emerged, you can address it. If a continuation discussion is needed, you
can have it. If you are completely drained of any energy, you can spend
a quiet time together with a lighter agenda, or no agenda at all.
It would still be open for everyone, but the placement (Friday) and
title in the schedule (X contributors gathering) should feel
unattractive enough so that attendance is generally smaller and more
on-topic. We'll likely have to split rooms, so people who have been
complaining about giant rooms being detrimental should be happy too.
+1 I have no idea if this will work, but it definitely seems worth
trying and will help inform our planning for the L design summit at a
point where we'll still have some flexibility.
I do hope that contributors will emphasize to their respective finance
departments that the X contributors gathering is the potentially the
_most_ important part of the whole conference, not an opportunity to
skip out early and avoid an extra night's hotel stay. If all of the key
people are in the room it may even save a bunch of people a trip to a
mid-cycle meetup.
cheers,
Zane.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On 8/27/2014 8:51 AM, Thierry Carrez wrote:
better use of our 4 days
Will the design space be available on the fifth day too?
No need to schedule anything on that day (Day 0), but having the space
available would be nice for ad hoc gatherings.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
If anything, I’d like to have fewer cross-project tracks running
simultaneously. Depending on which are proposed, maybe we can make that happen.
On the other hand, cross-project issues is a big theme right now so maybe we
should consider devoting more than a day to dealing with them.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
The message I’m getting from this change in available space is that we need to
start thinking about and writing up ideas early, so teams can figure out which
upcoming specs need more discussion and which don’t.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
This is a good compromise between needing to allow folks to move around between
tracks (including speaking at the conference) and having a large block of
unstructured time for deep dives.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On 08/27/2014 03:26 PM, Sean Dague wrote:
On 08/27/2014 08:51 AM, Thierry Carrez wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
I definitely like this approach. I think it will be really interesting
to collect feedback from people about the value they got from days 2 3
vs. Day 4.
I also wonder if we should lose a slot from days 1 - 3 and expand the
hallway time. Hallway track is always pretty interesting, and honestly
at a lot of interesting ideas spring up. The 10 minute transitions often
seem to feel like you are rushing between places too quickly some times.
+1
Last summit, it was basically impossible to do any hallway talking and
even meet some folks face-2-face.
Other than that, I think the proposal is great and makes sense to me.
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco fla...@redhat.com wrote:
On 08/27/2014 03:26 PM, Sean Dague wrote:
On 08/27/2014 08:51 AM, Thierry Carrez wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
I definitely like this approach. I think it will be really interesting
to collect feedback from people about the value they got from days 2 3
vs. Day 4.
I also wonder if we should lose a slot from days 1 - 3 and expand the
hallway time. Hallway track is always pretty interesting, and honestly
at a lot of interesting ideas spring up. The 10 minute transitions often
seem to feel like you are rushing between places too quickly some times.
+1
Last summit, it was basically impossible to do any hallway talking and
even meet some folks face-2-face.
Other than that, I think the proposal is great and makes sense to me.
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
​Sounds like a great idea to me:
+1​
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez thie...@openstack.org wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
Cheers,
+1000
This is a great move in the right direction here. Evolving the design
summit in this direction feels natural and will greatly benefit the
projects by allowing for some flexibility and taking some of the good
points from mid-cycle meetings and incorporating it here.
Thanks,
Kyle
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On 08/27/2014 02:46 PM, John Griffith wrote:
On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco fla...@redhat.com wrote:
On 08/27/2014 03:26 PM, Sean Dague wrote:
On 08/27/2014 08:51 AM, Thierry Carrez wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
I definitely like this approach. I think it will be really interesting
to collect feedback from people about the value they got from days 2 3
vs. Day 4.
I also wonder if we should lose a slot from days 1 - 3 and expand the
hallway time. Hallway track is always pretty interesting, and honestly
at a lot of interesting ideas spring up. The 10 minute transitions often
seem to feel like you are rushing between places too quickly some times.
+1
Last summit, it was basically impossible to do any hallway talking and
even meet some folks face-2-face.
Other than that, I think the proposal is great and makes sense to me.
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
​Sounds like a great idea to me:
+1​
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I think this is a great direction.
Here is my dilemma and it might just affect me. I attended 3 mid-cycles
this release: one of Neutron's (there were 2), QA/Infra and Cinder. The
Neutron and Cinder ones were mostly in pursuit of figuring out third
party and exchanging information surrounding that (which I feel was
successful). The QA/Infra one was, well even though I feel like I have
been awol, I still consider this my home.
From my perspective and check with Neutron and Cinder to see if they
agree, but having at least one person from qa/infra at a mid-cycle helps
in small ways. At both I worked with folks to help them make more
efficient use of their review time by exploring gerrit queries (there
were people who didn't know this magic, nor did they think to ask until
they saw some dashboards), at Neutron I gave my impromtu
this-is-how-infra-testing-works in terms of the moving parts, and
fortunately managed to work in a

On Wed, Aug 27, 2014 at 2:48 PM, Anita Kuno ante...@anteaya.info wrote:
On 08/27/2014 02:46 PM, John Griffith wrote:
On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco fla...@redhat.com
wrote:
On 08/27/2014 03:26 PM, Sean Dague wrote:
On 08/27/2014 08:51 AM, Thierry Carrez wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design
Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for
Paris,
within the constraints we have (already booked space and time). Here
is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the
various
experiments we conducted during juno. Don't hesitate to schedule 2
slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space
allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea
would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing
in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can
conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the
discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together
to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
I definitely like this approach. I think it will be really interesting
to collect feedback from people about the value they got from days 2
3
vs. Day 4.
I also wonder if we should lose a slot from days 1 - 3 and expand the
hallway time. Hallway track is always pretty interesting, and honestly
at a lot of interesting ideas spring up. The 10 minute transitions
often
seem to feel like you are rushing between places too quickly some
times.
+1
Last summit, it was basically impossible to do any hallway talking and
even meet some folks face-2-face.
Other than that, I think the proposal is great and makes sense to me.
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
​Sounds like a great idea to me:
+1​
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I think this is a great direction.
Here is my dilemma and it might just affect me. I attended 3 mid-cycles
this release: one of Neutron's (there were 2), QA/Infra and Cinder. The
Neutron and Cinder ones were mostly in pursuit of figuring out third
party and exchanging information surrounding that (which I feel was
successful). The QA/Infra one was, well even though I feel like I have
been awol, I still consider this my home.
From my perspective and check with Neutron and Cinder to see if they
agree, but having at least one person from qa/infra at a mid-cycle helps
in small ways. At both I worked with folks to help them make more
efficient use of their review time by exploring gerrit queries (there
were people who didn't know this magic, nor did

Excerpts from Thierry Carrez's message of 2014-08-27 05:51:55 -0700:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
I like it. The only thing I would add is that it would be quite useful if
the use of pods were at least partially enhanced by an unconference style
interest list. What I mean is, on day 1 have people suggest topics and
vote on suggested topics to discuss at the pods, and from then on the pods
can host these topics. This is for the other things that aren't well
defined until the summit and don't have their own rooms for days 2 and 3.
This is driven by the fact that the pods in Atlanta were almost always
busy doing something other than whatever the track that owned them
wanted. A few projects pods grew to 30-40 people a few times, eating up
all the chairs for the surrounding pods. TripleO often sat at the Heat
pod because of this for instance.
I don't think they should be fully scheduled. They're also just great
places to gather and have a good discussion, but it would be useful to
plan for topic flexibility and help coalesce interested parties, rather
than have them be silos that get taken over randomly. Especially since
there is a temptation to push the other topics to them already.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
Love this. Please if we can also fully enclose these meetups and the
session rooms in dry erase boards that would be ideal.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Excerpts from Sean Dague's message of 2014-08-27 06:26:38 -0700:
On 08/27/2014 08:51 AM, Thierry Carrez wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
I definitely like this approach. I think it will be really interesting
to collect feedback from people about the value they got from days 2 3
vs. Day 4.
I also wonder if we should lose a slot from days 1 - 3 and expand the
hallway time. Hallway track is always pretty interesting, and honestly
at a lot of interesting ideas spring up. The 10 minute transitions often
seem to feel like you are rushing between places too quickly some times.
Yes please. I'd also be fine with just giving back 5 minutes from each
session to facilitate this.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Excerpts from Anita Kuno's message of 2014-08-27 13:48:25 -0700:
On 08/27/2014 02:46 PM, John Griffith wrote:
On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco fla...@redhat.com wrote:
On 08/27/2014 03:26 PM, Sean Dague wrote:
On 08/27/2014 08:51 AM, Thierry Carrez wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
I definitely like this approach. I think it will be really interesting
to collect feedback from people about the value they got from days 2 3
vs. Day 4.
I also wonder if we should lose a slot from days 1 - 3 and expand the
hallway time. Hallway track is always pretty interesting, and honestly
at a lot of interesting ideas spring up. The 10 minute transitions often
seem to feel like you are rushing between places too quickly some times.
+1
Last summit, it was basically impossible to do any hallway talking and
even meet some folks face-2-face.
Other than that, I think the proposal is great and makes sense to me.
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
​Sounds like a great idea to me:
+1​
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I think this is a great direction.
Here is my dilemma and it might just affect me. I attended 3 mid-cycles
this release: one of Neutron's (there were 2), QA/Infra and Cinder. The
Neutron and Cinder ones were mostly in pursuit of figuring out third
party and exchanging information surrounding that (which I feel was
successful). The QA/Infra one was, well even though I feel like I have
been awol, I still consider this my home.
From my perspective and check with Neutron and Cinder to see if they
agree, but having at least one person from qa/infra at a mid-cycle helps
in small ways. At both I worked with folks to help them make more
efficient use of their review time by exploring gerrit queries (there
were people who didn't know this magic, nor did they think to ask

On 08/27/2014 07:39 PM, Chris Jones wrote:
Hi Anita
Your impromptu infra-clue-dissemination talks sound interesting (I'd like to
see the elastic recheck fingerprint one, for example). Would it make sense to
amplify your reach, by making some short screencasts of these sorts of things?
Cheers,
--
Chris Jones
/me sobs
I tried to have that on my list a year ago and it kept getting shoved
down. :( It isn't that I'm not capable, it is that I have little energy
atm especially without a live audience. I'm also very picky about the
editing (having worked in film). I don't have a timeline when I can say
this would happen, at least from me.
The knowledge isn't specific to me, if someone else is inclined.
Thanks Chris, I appreciate the encouragement,
Anita.
On 27 Aug 2014, at 21:48, Anita Kuno ante...@anteaya.info wrote:
On 08/27/2014 02:46 PM, John Griffith wrote:
On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco fla...@redhat.com wrote:
On 08/27/2014 03:26 PM, Sean Dague wrote:
On 08/27/2014 08:51 AM, Thierry Carrez wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
I definitely like this approach. I think it will be really interesting
to collect feedback from people about the value they got from days 2 3
vs. Day 4.
I also wonder if we should lose a slot from days 1 - 3 and expand the
hallway time. Hallway track is always pretty interesting, and honestly
at a lot of interesting ideas spring up. The 10 minute transitions often
seem to feel like you are rushing between places too quickly some times.
+1
Last summit, it was basically impossible to do any hallway talking and
even meet some folks face-2-face.
Other than that, I think the proposal is great and makes sense to me.
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
​Sounds like a great idea to me:
+1​
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I think this is a great direction.
Here is my dilemma and it might just affect me. I attended 3 mid-cycles

On August 27, 2014 3:26 PM Clint Byrum wrote:
Excerpts from Thierry Carrez's message of 2014-08-27 05:51:55:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
I like it. The only thing I would add is that it would be quite useful if
the use of pods were at least partially enhanced by an unconference style
interest list. What I mean is, on day 1 have people suggest topics and
vote on suggested topics to discuss at the pods, and from then on the pods
can host these topics. This is for the other things that aren't well
defined until the summit and don't have their own rooms for days 2 and 3.
[Rocky Grober] +100 the only thing I would add is that each morning, the
unconference could vote for that day (or half day for that matter), that way,
if a session or sessions from the day before generated greater interest in
something either not listed or with low votes, the morning vote could shift
priorities towards the now higher interest topic.
--Rocky
This is driven by the fact that the pods in Atlanta were almost always
busy doing something other than whatever the track that owned them
wanted. A few projects pods grew to 30-40 people a few times, eating up
all the chairs for the surrounding pods. TripleO often sat at the Heat
pod because of this for instance.
I don't think they should be fully scheduled. They're also just great
places to gather and have a good discussion, but it would be useful to
plan for topic flexibility and help coalesce interested parties, rather
than have them be silos that get taken over randomly. Especially since
there is a temptation to push the other topics to them already.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

From: Chris Jones [mailto:c...@tenshu.net]
Hi Anita
Your impromptu infra-clue-dissemination talks sound interesting (I'd like to
see the elastic recheck fingerprint one, for example). Would it make sense to
amplify your reach, by making some short screencasts of these sorts of things?
Cheers,
--
Chris Jones
[Rocky Grober] +1 or a session at Paris that is recorded?
On 27 Aug 2014, at 21:48, Anita Kuno ante...@anteaya.info wrote:
On 08/27/2014 02:46 PM, John Griffith wrote:
On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco fla...@redhat.com wrote:
On 08/27/2014 03:26 PM, Sean Dague wrote:
On 08/27/2014 08:51 AM, Thierry Carrez wrote:
Hi everyone,
I've been thinking about what changes we can bring to the Design Summit
format to make it more productive. I've heard the feedback from the
mid-cycle meetups and would like to apply some of those ideas for Paris,
within the constraints we have (already booked space and time). Here is
something we could do:
Day 1. Cross-project sessions / incubated projects / other projects
I think that worked well last time. 3 parallel rooms where we can
address top cross-project questions, discuss the results of the various
experiments we conducted during juno. Don't hesitate to schedule 2 slots
for discussions, so that we have time to come to the bottom of those
issues. Incubated projects (and maybe other projects, if space allows)
occupy the remaining space on day 1, and could occupy pods on the
other days.
Day 2 and Day 3. Scheduled sessions for various programs
That's our traditional scheduled space. We'll have a 33% less slots
available. So, rather than trying to cover all the scope, the idea would
be to focus those sessions on specific issues which really require
face-to-face discussion (which can't be solved on the ML or using spec
discussion) *or* require a lot of user feedback. That way, appearing in
the general schedule is very helpful. This will require us to be a lot
stricter on what we accept there and what we don't -- we won't have
space for courtesy sessions anymore, and traditional/unnecessary
sessions (like my traditional release schedule one) should just move
to the mailing-list.
Day 4. Contributors meetups
On the last day, we could try to split the space so that we can conduct
parallel midcycle-meetup-like contributors gatherings, with no time
boundaries and an open agenda. Large projects could get a full day,
smaller projects would get half a day (but could continue the discussion
in a local bar). Ideally that meetup would end with some alignment on
release goals, but the idea is to make the best of that time together to
solve the issues you have. Friday would finish with the design summit
feedback session, for those who are still around.
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and broader attendance, then try to replicate the
success of midcycle meetup-like open unscheduled time to discuss
whatever is hot at this point.
There are still details to work out (is it possible split the space,
should we use the usual design summit CFP website to organize the
scheduled time...), but I would first like to have your feedback on
this format. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
I definitely like this approach. I think it will be really interesting
to collect feedback from people about the value they got from days 2 3
vs. Day 4.
I also wonder if we should lose a slot from days 1 - 3 and expand the
hallway time. Hallway track is always pretty interesting, and honestly
at a lot of interesting ideas spring up. The 10 minute transitions often
seem to feel like you are rushing between places too quickly some times.
+1
Last summit, it was basically impossible to do any hallway talking and
even meet some folks face-2-face.
Other than that, I think the proposal is great and makes sense to me.
Flavio
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
​Sounds like a great idea to me:
+1​
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I think this is a great direction.
Here is my dilemma and it might just affect me. I attended 3 mid-cycles
this release: one of Neutron's (there were 2), QA/Infra and Cinder. The
Neutron and Cinder ones were mostly in pursuit of figuring out third
party and exchanging information surrounding that (which I feel was
successful). The QA/Infra one was, well even though I feel like I have
been awol, I still consider this my home.
From my perspective and check with Neutron