Re: [openstack-dev] [all] Design Summit reloaded

[Thierry Carrez]

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

Re: [openstack-dev] [all] Design Summit reloaded

[Eoghan Glynn]

> > 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

Re: [openstack-dev] [all] Design Summit reloaded

[Thierry Carrez]

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

Re: [openstack-dev] [all] Design Summit reloaded

[Eoghan Glynn]

> 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

Re: [openstack-dev] [all] Design Summit reloaded

[Thierry Carrez]

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

Re: [openstack-dev] [all] Design Summit reloaded

[Hayes, Graham]

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

Re: [openstack-dev] [all] Design Summit reloaded

[Thierry Carrez]

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

Re: [openstack-dev] [all] Design Summit reloaded

[Hayes, Graham]

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  > > 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

Re: [openstack-dev] [all] Design Summit reloaded

[Thierry Carrez]

Anne Gentle wrote:
> On Wed, Aug 27, 2014 at 7: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.
> 
> 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

Re: [openstack-dev] [all] Design Summit reloaded

[Thierry Carrez]

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 
> 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

Re: [openstack-dev] [all] Design Summit reloaded

[Doug Hellmann]

On Aug 28, 2014, at 3: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 
> 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

Re: [openstack-dev] [all] Design Summit reloaded

[Anita Kuno]

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 
> 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 res

Re: [openstack-dev] [all] Design Summit reloaded

[Jay Pipes]

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 
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

Re: [openstack-dev] [all] Design Summit reloaded

[Anne Gentle]

On Wed, Aug 27, 2014 at 7: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.
>
>
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

Re: [openstack-dev] [all] Design Summit reloaded

[Sean Dague]

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 
 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

Re: [openstack-dev] [all] Design Summit reloaded

[Jay Pipes]

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 
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

Re: [openstack-dev] [all] Design Summit reloaded

[Sean Dague]

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 
>> 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 a

Re: [openstack-dev] [all] Design Summit reloaded

[Jay Pipes]

On 08/27/2014 11:34 AM, Doug Hellmann wrote:


On Aug 27, 2014, at 8: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.


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




_

Re: [openstack-dev] [all] Design Summit reloaded

[Rochelle.RochelleGrober]

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  wrote:
> 
>> On 08/27/2014 02:46 PM, John Griffith wrote:
>>> On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco  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

Re: [openstack-dev] [all] Design Summit reloaded

[Rochelle.RochelleGrober]

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

Re: [openstack-dev] [all] Design Summit reloaded

[Anita Kuno]

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  wrote:
>>
>>> On 08/27/2014 02:46 PM, John Griffith wrote:
 On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco  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 lis

Re: [openstack-dev] [all] Design Summit reloaded

[Chris Jones]

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

> On 27 Aug 2014, at 21:48, Anita Kuno  wrote:
> 
>> On 08/27/2014 02:46 PM, John Griffith wrote:
>>> On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco  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 m

Re: [openstack-dev] [all] Design Summit reloaded

[Clint Byrum]

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  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
> 

Re: [openstack-dev] [all] Design Summit reloaded

[Clint Byrum]

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

Re: [openstack-dev] [all] Design Summit reloaded

[Clint Byrum]

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

Re: [openstack-dev] [all] Design Summit reloaded

[John Griffith]

On Wed, Aug 27, 2014 at 2:48 PM, Anita Kuno  wrote:

> On 08/27/2014 02:46 PM, John Griffith wrote:
> > On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco 
> 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 li

Re: [openstack-dev] [all] Design Summit reloaded

[Anita Kuno]

On 08/27/2014 02:46 PM, John Griffith wrote:
> On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco  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 r

Re: [openstack-dev] [all] Design Summit reloaded

[Kyle Mestery]

On Wed, Aug 27, 2014 at 7: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.
>
> 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

Re: [openstack-dev] [all] Design Summit reloaded

[John Griffith]

On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco  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

Re: [openstack-dev] [all] Design Summit reloaded

[Flavio Percoco]

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

Re: [openstack-dev] [all] Design Summit reloaded

[Doug Hellmann]

On Aug 27, 2014, at 8: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.

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

Re: [openstack-dev] [all] Design Summit reloaded

[Henry Gessau]

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

Re: [openstack-dev] [all] Design Summit reloaded

[Zane Bitter]

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

Re: [openstack-dev] [all] Design Summit reloaded

[Thierry Carrez]

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.

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Design Summit reloaded

[Daniel P. Berrange]

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

Re: [openstack-dev] [all] Design Summit reloaded

[Sean Dague]

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

Re: [openstack-dev] [all] Design Summit reloaded

[Russell Bryant]

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

[openstack-dev] [all] Design Summit reloaded

[Thierry Carrez]

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,

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev