Re: [openstack-dev] [all] Design Summit reloaded
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
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
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
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
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
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
Sean Dague wrote: On 08/28/2014 03:06 PM, Jay Pipes wrote: On 08/28/2014 02:21 PM, Sean Dague wrote: On 08/28/2014 01:58 PM, Jay Pipes wrote: On 08/27/2014 11:34 AM, Doug Hellmann wrote: On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org wrote: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. If anything, I’d like to have fewer cross-project tracks running simultaneously. Depending on which are proposed, maybe we can make that happen. On the other hand, cross-project issues is a big theme right now so maybe we should consider devoting more than a day to dealing with them. I agree with Doug here. I'd almost say having a single cross-project room, with serialized content would be better than 3 separate cross-project tracks. By nature, the cross-project sessions will attract developers that work or are interested in a set of projects that looks like a big Venn diagram. By having 3 separate cross-project tracks, we would increase the likelihood that developers would once more have to choose among simultaneous sessions that they have equal interest in. For Infra and QA folks, this likelihood is even greater... I think I'd prefer a single cross-project track on the first day. So the fallout of that is there will be 6 or 7 cross-project slots for the design summit. Maybe that's the right mix if the TC does a good job picking the top 5 things we want accomplished from a cross project standpoint during the cycle. But it's going to have to be a pretty directed pick. I think last time we had 21 slots, and with a couple of doubling up that gave 19 sessions. (about 30 - 35 proposals for that slot set). I'm not sure that would be a bad thing :) I think one of the reasons the mid-cycles have been successful is that they have adequately limited the scope of discussions and I think by doing our homework by fully vetting and voting on cross-project sessions and being OK with saying No, not this time., we will be more productive than if we had 20+ cross-project sessions. Just my two cents, though.. I'm not sure it would be a bad thing either. I just wanted to be explicit about what we are saying the cross projects sessions are for in this case: the 5 key cross project activities the TC believes should be worked on this next cycle. There is a trade-off here. Parallel cross-project tracks let us address more issues in the limited time we have, and they also let us split the audience so that we don't end up at 500 in the same room and nothing gets done in 40min. It's true that sometimes you wish you could be in two different places at the same time, but we generally prevent the most blatant collisions during scheduling, and sometimes forcing people to choose what they really care about is not that bad. The feedback I got from Atlanta was that the 3-parallel-room setup went well, and there weren't that many conflicts. Maybe having *2* cross-project topics running at the same time (instead of 3 or 1) would be the right trade-off. We would still need to be more picky in selecting which issues we want to address, we would split the audience into two rooms, and we would reduce the likelihood of conflict significantly. The other question is if we did that what's running in competition to cross project day? Is it another free form pod day for people not working on those things? The 3 or 4 other rooms would give incubated projects (and other projects) some scheduled time. It also runs at the same time as the conference. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit reloaded
Anne Gentle wrote: On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. Yep, I think this works in theory, the tough part will be when all the incubating projects realize they're sending people for a single day? Maybe it'll work out differently than I think though. It means fitting ironic, barbican, designate, manila, marconi in a day? Actually those projects would get pod space for the rest of the week, so they should stay! Also some of them might have graduated by then :) Also since QA, Infra, and Docs are cross-project AND Programs, where do they land? I think those teams work on different issues. Some issues require a lot of communication and input because they are cross-project problems that those teams are tasked with solving -- in which case that belongs to the cross-project day. Other issues are more implementation details and require mostly the team members but not so much external input -- those belong to the specific slots or the contributors meetup. Obviously some things will be a bit borderline and we'll have to pick one or the other based on available slots. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit reloaded
On Fri, 2014-08-29 at 11:23 +0200, Thierry Carrez wrote: Anne Gentle wrote: On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. Yep, I think this works in theory, the tough part will be when all the incubating projects realize they're sending people for a single day? Maybe it'll work out differently than I think though. It means fitting ironic, barbican, designate, manila, marconi in a day? Actually those projects would get pod space for the rest of the week, so they should stay! Also some of them might have graduated by then :) Would the programs for those projects not get design summit time? I thought the Programs got Design summit time, not projects... If not, can the Programs get design summit time? Also since QA, Infra, and Docs are cross-project AND Programs, where do they land? I think those teams work on different issues. Some issues require a lot of communication and input because they are cross-project problems that those teams are tasked with solving -- in which case that belongs to the cross-project day. Other issues are more implementation details and require mostly the team members but not so much external input -- those belong to the specific slots or the contributors meetup. Obviously some things will be a bit borderline and we'll have to pick one or the other based on available slots. signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit reloaded
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
On 08/27/2014 11:34 AM, Doug Hellmann wrote: On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. If anything, I’d like to have fewer cross-project tracks running simultaneously. Depending on which are proposed, maybe we can make that happen. On the other hand, cross-project issues is a big theme right now so maybe we should consider devoting more than a day to dealing with them. I agree with Doug here. I'd almost say having a single cross-project room, with serialized content would be better than 3 separate cross-project tracks. By nature, the cross-project sessions will attract developers that work or are interested in a set of projects that looks like a big Venn diagram. By having 3 separate cross-project tracks, we would increase the likelihood that developers would once more have to choose among simultaneous sessions that they have equal interest in. For Infra and QA folks, this likelihood is even greater... I think I'd prefer a single cross-project track on the first day. Day 2 and Day 3. Scheduled sessions for various programs That's our traditional scheduled space. We'll have a 33% less slots available. So, rather than trying to cover all the scope, the idea would be to focus those sessions on specific issues which really require face-to-face discussion (which can't be solved on the ML or using spec discussion) *or* require a lot of user feedback. That way, appearing in the general schedule is very helpful. This will require us to be a lot stricter on what we accept there and what we don't -- we won't have space for courtesy sessions anymore, and traditional/unnecessary sessions (like my traditional release schedule one) should just move to the mailing-list. The message I’m getting from this change in available space is that we need to start thinking about and writing up ideas early, so teams can figure out which upcoming specs need more discussion and which don’t. ++ Also, I think as a community we need to get much better about saying No for certain things. No to sessions that don't have much specific details to them. No to blueprints that don't add much functionality that cannot be widely used or taken advantage of. No to specs that don't have a narrow-enough scope, etc. I also think we need to be better at saying Yes to other things, though... but that's a different thread ;) Day 4. Contributors meetups On the last day, we could try to split the space so that we can conduct parallel midcycle-meetup-like contributors gatherings, with no time boundaries and an open agenda. Large projects could get a full day, smaller projects would get half a day (but could continue the discussion in a local bar). Ideally that meetup would end with some alignment on release goals, but the idea is to make the best of that time together to solve the issues you have. Friday would finish with the design summit feedback session, for those who are still around. This is a good compromise between needing to allow folks to move around between tracks (including speaking at the conference) and having a large block of unstructured time for deep dives. Agreed. Best, -jay I think this proposal makes the best use of our setup: discuss clear cross-project issues, address key specific topics which need face-to-face time and broader attendance, then try to replicate the success of midcycle meetup-like open unscheduled time to discuss whatever is hot at this point. There are still details to work out (is it possible split the space, should we use the usual design summit CFP website to organize the scheduled time...), but I would first like to have your feedback on this format. Also if you have alternative proposals that would make a better use of our 4 days, let me know. Cheers, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit reloaded
On 08/28/2014 01:58 PM, Jay Pipes wrote: On 08/27/2014 11:34 AM, Doug Hellmann wrote: On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. If anything, I’d like to have fewer cross-project tracks running simultaneously. Depending on which are proposed, maybe we can make that happen. On the other hand, cross-project issues is a big theme right now so maybe we should consider devoting more than a day to dealing with them. I agree with Doug here. I'd almost say having a single cross-project room, with serialized content would be better than 3 separate cross-project tracks. By nature, the cross-project sessions will attract developers that work or are interested in a set of projects that looks like a big Venn diagram. By having 3 separate cross-project tracks, we would increase the likelihood that developers would once more have to choose among simultaneous sessions that they have equal interest in. For Infra and QA folks, this likelihood is even greater... I think I'd prefer a single cross-project track on the first day. So the fallout of that is there will be 6 or 7 cross-project slots for the design summit. Maybe that's the right mix if the TC does a good job picking the top 5 things we want accomplished from a cross project standpoint during the cycle. But it's going to have to be a pretty directed pick. I think last time we had 21 slots, and with a couple of doubling up that gave 19 sessions. (about 30 - 35 proposals for that slot set). Day 2 and Day 3. Scheduled sessions for various programs That's our traditional scheduled space. We'll have a 33% less slots available. So, rather than trying to cover all the scope, the idea would be to focus those sessions on specific issues which really require face-to-face discussion (which can't be solved on the ML or using spec discussion) *or* require a lot of user feedback. That way, appearing in the general schedule is very helpful. This will require us to be a lot stricter on what we accept there and what we don't -- we won't have space for courtesy sessions anymore, and traditional/unnecessary sessions (like my traditional release schedule one) should just move to the mailing-list. The message I’m getting from this change in available space is that we need to start thinking about and writing up ideas early, so teams can figure out which upcoming specs need more discussion and which don’t. ++ Also, I think as a community we need to get much better about saying No for certain things. No to sessions that don't have much specific details to them. No to blueprints that don't add much functionality that cannot be widely used or taken advantage of. No to specs that don't have a narrow-enough scope, etc. I also think we need to be better at saying Yes to other things, though... but that's a different thread ;) Day 4. Contributors meetups On the last day, we could try to split the space so that we can conduct parallel midcycle-meetup-like contributors gatherings, with no time boundaries and an open agenda. Large projects could get a full day, smaller projects would get half a day (but could continue the discussion in a local bar). Ideally that meetup would end with some alignment on release goals, but the idea is to make the best of that time together to solve the issues you have. Friday would finish with the design summit feedback session, for those who are still around. This is a good compromise between needing to allow folks to move around between tracks (including speaking at the conference) and having a large block of unstructured time for deep dives. Agreed. Best, -jay I think this proposal makes the best use of our setup: discuss clear cross-project issues, address key specific topics which need face-to-face time and broader attendance, then try to replicate the success of midcycle meetup-like open unscheduled time to discuss whatever is hot at this point. There are still details to work out (is it possible split the space, should we use the usual design summit CFP website to organize the scheduled time...), but I would first like
Re: [openstack-dev] [all] Design Summit reloaded
On 08/28/2014 02:21 PM, Sean Dague wrote: On 08/28/2014 01:58 PM, Jay Pipes wrote: On 08/27/2014 11:34 AM, Doug Hellmann wrote: On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. If anything, I’d like to have fewer cross-project tracks running simultaneously. Depending on which are proposed, maybe we can make that happen. On the other hand, cross-project issues is a big theme right now so maybe we should consider devoting more than a day to dealing with them. I agree with Doug here. I'd almost say having a single cross-project room, with serialized content would be better than 3 separate cross-project tracks. By nature, the cross-project sessions will attract developers that work or are interested in a set of projects that looks like a big Venn diagram. By having 3 separate cross-project tracks, we would increase the likelihood that developers would once more have to choose among simultaneous sessions that they have equal interest in. For Infra and QA folks, this likelihood is even greater... I think I'd prefer a single cross-project track on the first day. So the fallout of that is there will be 6 or 7 cross-project slots for the design summit. Maybe that's the right mix if the TC does a good job picking the top 5 things we want accomplished from a cross project standpoint during the cycle. But it's going to have to be a pretty directed pick. I think last time we had 21 slots, and with a couple of doubling up that gave 19 sessions. (about 30 - 35 proposals for that slot set). I'm not sure that would be a bad thing :) I think one of the reasons the mid-cycles have been successful is that they have adequately limited the scope of discussions and I think by doing our homework by fully vetting and voting on cross-project sessions and being OK with saying No, not this time., we will be more productive than if we had 20+ cross-project sessions. Just my two cents, though.. -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit reloaded
On 08/28/2014 03:06 PM, Jay Pipes wrote: On 08/28/2014 02:21 PM, Sean Dague wrote: On 08/28/2014 01:58 PM, Jay Pipes wrote: On 08/27/2014 11:34 AM, Doug Hellmann wrote: On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. If anything, I’d like to have fewer cross-project tracks running simultaneously. Depending on which are proposed, maybe we can make that happen. On the other hand, cross-project issues is a big theme right now so maybe we should consider devoting more than a day to dealing with them. I agree with Doug here. I'd almost say having a single cross-project room, with serialized content would be better than 3 separate cross-project tracks. By nature, the cross-project sessions will attract developers that work or are interested in a set of projects that looks like a big Venn diagram. By having 3 separate cross-project tracks, we would increase the likelihood that developers would once more have to choose among simultaneous sessions that they have equal interest in. For Infra and QA folks, this likelihood is even greater... I think I'd prefer a single cross-project track on the first day. So the fallout of that is there will be 6 or 7 cross-project slots for the design summit. Maybe that's the right mix if the TC does a good job picking the top 5 things we want accomplished from a cross project standpoint during the cycle. But it's going to have to be a pretty directed pick. I think last time we had 21 slots, and with a couple of doubling up that gave 19 sessions. (about 30 - 35 proposals for that slot set). I'm not sure that would be a bad thing :) I think one of the reasons the mid-cycles have been successful is that they have adequately limited the scope of discussions and I think by doing our homework by fully vetting and voting on cross-project sessions and being OK with saying No, not this time., we will be more productive than if we had 20+ cross-project sessions. Just my two cents, though.. I'm not sure it would be a bad thing either. I just wanted to be explicit about what we are saying the cross projects sessions are for in this case: the 5 key cross project activities the TC believes should be worked on this next cycle. The other question is if we did that what's running in competition to cross project day? Is it another free form pod day for people not working on those things? -Sean -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit reloaded
On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. Yep, I think this works in theory, the tough part will be when all the incubating projects realize they're sending people for a single day? Maybe it'll work out differently than I think though. It means fitting ironic, barbican, designate, manila, marconi in a day? Also since QA, Infra, and Docs are cross-project AND Programs, where do they land? Day 2 and Day 3. Scheduled sessions for various programs That's our traditional scheduled space. We'll have a 33% less slots available. So, rather than trying to cover all the scope, the idea would be to focus those sessions on specific issues which really require face-to-face discussion (which can't be solved on the ML or using spec discussion) *or* require a lot of user feedback. That way, appearing in the general schedule is very helpful. This will require us to be a lot stricter on what we accept there and what we don't -- we won't have space for courtesy sessions anymore, and traditional/unnecessary sessions (like my traditional release schedule one) should just move to the mailing-list. I like thinking about what we can move to the mailing lists. Nice. Day 4. Contributors meetups On the last day, we could try to split the space so that we can conduct parallel midcycle-meetup-like contributors gatherings, with no time boundaries and an open agenda. Large projects could get a full day, smaller projects would get half a day (but could continue the discussion in a local bar). Ideally that meetup would end with some alignment on release goals, but the idea is to make the best of that time together to solve the issues you have. Friday would finish with the design summit feedback session, for those who are still around. Sounds good. I think this proposal makes the best use of our setup: discuss clear cross-project issues, address key specific topics which need face-to-face time and broader attendance, then try to replicate the success of midcycle meetup-like open unscheduled time to discuss whatever is hot at this point. There are still details to work out (is it possible split the space, should we use the usual design summit CFP website to organize the scheduled time...), but I would first like to have your feedback on this format. Also if you have alternative proposals that would make a better use of our 4 days, let me know. Cheers, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit reloaded
On 08/28/2014 03:31 PM, Sean Dague wrote: On 08/28/2014 03:06 PM, Jay Pipes wrote: On 08/28/2014 02:21 PM, Sean Dague wrote: On 08/28/2014 01:58 PM, Jay Pipes wrote: On 08/27/2014 11:34 AM, Doug Hellmann wrote: On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. If anything, I’d like to have fewer cross-project tracks running simultaneously. Depending on which are proposed, maybe we can make that happen. On the other hand, cross-project issues is a big theme right now so maybe we should consider devoting more than a day to dealing with them. I agree with Doug here. I'd almost say having a single cross-project room, with serialized content would be better than 3 separate cross-project tracks. By nature, the cross-project sessions will attract developers that work or are interested in a set of projects that looks like a big Venn diagram. By having 3 separate cross-project tracks, we would increase the likelihood that developers would once more have to choose among simultaneous sessions that they have equal interest in. For Infra and QA folks, this likelihood is even greater... I think I'd prefer a single cross-project track on the first day. So the fallout of that is there will be 6 or 7 cross-project slots for the design summit. Maybe that's the right mix if the TC does a good job picking the top 5 things we want accomplished from a cross project standpoint during the cycle. But it's going to have to be a pretty directed pick. I think last time we had 21 slots, and with a couple of doubling up that gave 19 sessions. (about 30 - 35 proposals for that slot set). I'm not sure that would be a bad thing :) I think one of the reasons the mid-cycles have been successful is that they have adequately limited the scope of discussions and I think by doing our homework by fully vetting and voting on cross-project sessions and being OK with saying No, not this time., we will be more productive than if we had 20+ cross-project sessions. Just my two cents, though.. I'm not sure it would be a bad thing either. I just wanted to be explicit about what we are saying the cross projects sessions are for in this case: the 5 key cross project activities the TC believes should be worked on this next cycle. Yes. The other question is if we did that what's running in competition to cross project day? Is it another free form pod day for people not working on those things? It could be a pod day, sure. Or just an extended hallway session day... :) -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit reloaded
On 08/28/2014 03:31 PM, Sean Dague wrote: On 08/28/2014 03:06 PM, Jay Pipes wrote: On 08/28/2014 02:21 PM, Sean Dague wrote: On 08/28/2014 01:58 PM, Jay Pipes wrote: On 08/27/2014 11:34 AM, Doug Hellmann wrote: On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. If anything, I’d like to have fewer cross-project tracks running simultaneously. Depending on which are proposed, maybe we can make that happen. On the other hand, cross-project issues is a big theme right now so maybe we should consider devoting more than a day to dealing with them. I agree with Doug here. I'd almost say having a single cross-project room, with serialized content would be better than 3 separate cross-project tracks. By nature, the cross-project sessions will attract developers that work or are interested in a set of projects that looks like a big Venn diagram. By having 3 separate cross-project tracks, we would increase the likelihood that developers would once more have to choose among simultaneous sessions that they have equal interest in. For Infra and QA folks, this likelihood is even greater... I think I'd prefer a single cross-project track on the first day. So the fallout of that is there will be 6 or 7 cross-project slots for the design summit. Maybe that's the right mix if the TC does a good job picking the top 5 things we want accomplished from a cross project standpoint during the cycle. But it's going to have to be a pretty directed pick. I think last time we had 21 slots, and with a couple of doubling up that gave 19 sessions. (about 30 - 35 proposals for that slot set). I'm not sure that would be a bad thing :) I think one of the reasons the mid-cycles have been successful is that they have adequately limited the scope of discussions and I think by doing our homework by fully vetting and voting on cross-project sessions and being OK with saying No, not this time., we will be more productive than if we had 20+ cross-project sessions. Just my two cents, though.. I'm not sure it would be a bad thing either. I just wanted to be explicit about what we are saying the cross projects sessions are for in this case: the 5 key cross project activities the TC believes should be worked on this next cycle. The other question is if we did that what's running in competition to cross project day? Is it another free form pod day for people not working on those things? -Sean -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I'm curious to know how many people would be expected to be all in the same room? And what percentage of these folks are participating in the conversation and how many are audience? One of the issues that seem to be universal in the identified discontent area with summit sessions currently (which gets discussed after each of the mid-cycles) is that 30 people talking in a room with an audience of 200 isn't very efficient. I wonder if this well intentioned direction might end up with this result which many folks I talked to don't want. The other issue that comes to mind for me is trying to allow everyone to be included in the discussion while keeping it focusing and reducing the side conversations. If folks are impatient to have their point (or off topic joke) heard, they won't wait for a turn from whoever is chairing, they will just start talking. This can create tension for the rest of the folks who *are* patiently trying to wait their turn. I chaired a day and a half of discussions at the qa/infra mid-cycle (the rest of the time was code sprinting) and it was a real challenge in a room of 30 people with a full spectrum of contributor experience (at least one person made their first contribution in Germany plus there were folks who have been involved since the beginning) to keep everyone
Re: [openstack-dev] [all] Design Summit reloaded
On Aug 28, 2014, at 3:31 PM, Sean Dague s...@dague.net wrote: On 08/28/2014 03:06 PM, Jay Pipes wrote: On 08/28/2014 02:21 PM, Sean Dague wrote: On 08/28/2014 01:58 PM, Jay Pipes wrote: On 08/27/2014 11:34 AM, Doug Hellmann wrote: On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. If anything, I’d like to have fewer cross-project tracks running simultaneously. Depending on which are proposed, maybe we can make that happen. On the other hand, cross-project issues is a big theme right now so maybe we should consider devoting more than a day to dealing with them. I agree with Doug here. I'd almost say having a single cross-project room, with serialized content would be better than 3 separate cross-project tracks. By nature, the cross-project sessions will attract developers that work or are interested in a set of projects that looks like a big Venn diagram. By having 3 separate cross-project tracks, we would increase the likelihood that developers would once more have to choose among simultaneous sessions that they have equal interest in. For Infra and QA folks, this likelihood is even greater... I think I'd prefer a single cross-project track on the first day. So the fallout of that is there will be 6 or 7 cross-project slots for the design summit. Maybe that's the right mix if the TC does a good job picking the top 5 things we want accomplished from a cross project standpoint during the cycle. But it's going to have to be a pretty directed pick. I think last time we had 21 slots, and with a couple of doubling up that gave 19 sessions. (about 30 - 35 proposals for that slot set). I'm not sure that would be a bad thing :) I think one of the reasons the mid-cycles have been successful is that they have adequately limited the scope of discussions and I think by doing our homework by fully vetting and voting on cross-project sessions and being OK with saying No, not this time., we will be more productive than if we had 20+ cross-project sessions. Just my two cents, though.. I'm not sure it would be a bad thing either. I just wanted to be explicit about what we are saying the cross projects sessions are for in this case: the 5 key cross project activities the TC believes should be worked on this next cycle. We’ve talked about several cross-project needs recently. Let’s start a list of things we think we’re ready to make significant progress on during Kilo (not just things we *need* to do, but things we think we *can* do *now*): 1. logging cleanup and standardization The other question is if we did that what's running in competition to cross project day? Is it another free form pod day for people not working on those things? That seems like a good use of time. -Sean -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Design Summit reloaded
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
Re: [openstack-dev] [all] Design Summit reloaded
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
Re: [openstack-dev] [all] Design Summit reloaded
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
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
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
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
On Aug 27, 2014, at 8:51 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. If anything, I’d like to have fewer cross-project tracks running simultaneously. Depending on which are proposed, maybe we can make that happen. On the other hand, cross-project issues is a big theme right now so maybe we should consider devoting more than a day to dealing with them. Day 2 and Day 3. Scheduled sessions for various programs That's our traditional scheduled space. We'll have a 33% less slots available. So, rather than trying to cover all the scope, the idea would be to focus those sessions on specific issues which really require face-to-face discussion (which can't be solved on the ML or using spec discussion) *or* require a lot of user feedback. That way, appearing in the general schedule is very helpful. This will require us to be a lot stricter on what we accept there and what we don't -- we won't have space for courtesy sessions anymore, and traditional/unnecessary sessions (like my traditional release schedule one) should just move to the mailing-list. The message I’m getting from this change in available space is that we need to start thinking about and writing up ideas early, so teams can figure out which upcoming specs need more discussion and which don’t. Day 4. Contributors meetups On the last day, we could try to split the space so that we can conduct parallel midcycle-meetup-like contributors gatherings, with no time boundaries and an open agenda. Large projects could get a full day, smaller projects would get half a day (but could continue the discussion in a local bar). Ideally that meetup would end with some alignment on release goals, but the idea is to make the best of that time together to solve the issues you have. Friday would finish with the design summit feedback session, for those who are still around. This is a good compromise between needing to allow folks to move around between tracks (including speaking at the conference) and having a large block of unstructured time for deep dives. I think this proposal makes the best use of our setup: discuss clear cross-project issues, address key specific topics which need face-to-face time and broader attendance, then try to replicate the success of midcycle meetup-like open unscheduled time to discuss whatever is hot at this point. There are still details to work out (is it possible split the space, should we use the usual design summit CFP website to organize the scheduled time...), but I would first like to have your feedback on this format. Also if you have alternative proposals that would make a better use of our 4 days, let me know. Cheers, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit reloaded
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
On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco fla...@redhat.com wrote: On 08/27/2014 03:26 PM, Sean Dague wrote: On 08/27/2014 08:51 AM, Thierry Carrez wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. Day 2 and Day 3. Scheduled sessions for various programs That's our traditional scheduled space. We'll have a 33% less slots available. So, rather than trying to cover all the scope, the idea would be to focus those sessions on specific issues which really require face-to-face discussion (which can't be solved on the ML or using spec discussion) *or* require a lot of user feedback. That way, appearing in the general schedule is very helpful. This will require us to be a lot stricter on what we accept there and what we don't -- we won't have space for courtesy sessions anymore, and traditional/unnecessary sessions (like my traditional release schedule one) should just move to the mailing-list. Day 4. Contributors meetups On the last day, we could try to split the space so that we can conduct parallel midcycle-meetup-like contributors gatherings, with no time boundaries and an open agenda. Large projects could get a full day, smaller projects would get half a day (but could continue the discussion in a local bar). Ideally that meetup would end with some alignment on release goals, but the idea is to make the best of that time together to solve the issues you have. Friday would finish with the design summit feedback session, for those who are still around. I think this proposal makes the best use of our setup: discuss clear cross-project issues, address key specific topics which need face-to-face time and broader attendance, then try to replicate the success of midcycle meetup-like open unscheduled time to discuss whatever is hot at this point. There are still details to work out (is it possible split the space, should we use the usual design summit CFP website to organize the scheduled time...), but I would first like to have your feedback on this format. Also if you have alternative proposals that would make a better use of our 4 days, let me know. I definitely like this approach. I think it will be really interesting to collect feedback from people about the value they got from days 2 3 vs. Day 4. I also wonder if we should lose a slot from days 1 - 3 and expand the hallway time. Hallway track is always pretty interesting, and honestly at a lot of interesting ideas spring up. The 10 minute transitions often seem to feel like you are rushing between places too quickly some times. +1 Last summit, it was basically impossible to do any hallway talking and even meet some folks face-2-face. Other than that, I think the proposal is great and makes sense to me. Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Sounds like a great idea to me: +1 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit reloaded
On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. Day 2 and Day 3. Scheduled sessions for various programs That's our traditional scheduled space. We'll have a 33% less slots available. So, rather than trying to cover all the scope, the idea would be to focus those sessions on specific issues which really require face-to-face discussion (which can't be solved on the ML or using spec discussion) *or* require a lot of user feedback. That way, appearing in the general schedule is very helpful. This will require us to be a lot stricter on what we accept there and what we don't -- we won't have space for courtesy sessions anymore, and traditional/unnecessary sessions (like my traditional release schedule one) should just move to the mailing-list. Day 4. Contributors meetups On the last day, we could try to split the space so that we can conduct parallel midcycle-meetup-like contributors gatherings, with no time boundaries and an open agenda. Large projects could get a full day, smaller projects would get half a day (but could continue the discussion in a local bar). Ideally that meetup would end with some alignment on release goals, but the idea is to make the best of that time together to solve the issues you have. Friday would finish with the design summit feedback session, for those who are still around. I think this proposal makes the best use of our setup: discuss clear cross-project issues, address key specific topics which need face-to-face time and broader attendance, then try to replicate the success of midcycle meetup-like open unscheduled time to discuss whatever is hot at this point. There are still details to work out (is it possible split the space, should we use the usual design summit CFP website to organize the scheduled time...), but I would first like to have your feedback on this format. Also if you have alternative proposals that would make a better use of our 4 days, let me know. Cheers, +1000 This is a great move in the right direction here. Evolving the design summit in this direction feels natural and will greatly benefit the projects by allowing for some flexibility and taking some of the good points from mid-cycle meetings and incorporating it here. Thanks, Kyle -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit reloaded
On 08/27/2014 02:46 PM, John Griffith wrote: On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco fla...@redhat.com wrote: On 08/27/2014 03:26 PM, Sean Dague wrote: On 08/27/2014 08:51 AM, Thierry Carrez wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. Day 2 and Day 3. Scheduled sessions for various programs That's our traditional scheduled space. We'll have a 33% less slots available. So, rather than trying to cover all the scope, the idea would be to focus those sessions on specific issues which really require face-to-face discussion (which can't be solved on the ML or using spec discussion) *or* require a lot of user feedback. That way, appearing in the general schedule is very helpful. This will require us to be a lot stricter on what we accept there and what we don't -- we won't have space for courtesy sessions anymore, and traditional/unnecessary sessions (like my traditional release schedule one) should just move to the mailing-list. Day 4. Contributors meetups On the last day, we could try to split the space so that we can conduct parallel midcycle-meetup-like contributors gatherings, with no time boundaries and an open agenda. Large projects could get a full day, smaller projects would get half a day (but could continue the discussion in a local bar). Ideally that meetup would end with some alignment on release goals, but the idea is to make the best of that time together to solve the issues you have. Friday would finish with the design summit feedback session, for those who are still around. I think this proposal makes the best use of our setup: discuss clear cross-project issues, address key specific topics which need face-to-face time and broader attendance, then try to replicate the success of midcycle meetup-like open unscheduled time to discuss whatever is hot at this point. There are still details to work out (is it possible split the space, should we use the usual design summit CFP website to organize the scheduled time...), but I would first like to have your feedback on this format. Also if you have alternative proposals that would make a better use of our 4 days, let me know. I definitely like this approach. I think it will be really interesting to collect feedback from people about the value they got from days 2 3 vs. Day 4. I also wonder if we should lose a slot from days 1 - 3 and expand the hallway time. Hallway track is always pretty interesting, and honestly at a lot of interesting ideas spring up. The 10 minute transitions often seem to feel like you are rushing between places too quickly some times. +1 Last summit, it was basically impossible to do any hallway talking and even meet some folks face-2-face. Other than that, I think the proposal is great and makes sense to me. Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Sounds like a great idea to me: +1 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I think this is a great direction. Here is my dilemma and it might just affect me. I attended 3 mid-cycles this release: one of Neutron's (there were 2), QA/Infra and Cinder. The Neutron and Cinder ones were mostly in pursuit of figuring out third party and exchanging information surrounding that (which I feel was successful). The QA/Infra one was, well even though I feel like I have been awol, I still consider this my home. From my perspective and check with Neutron and Cinder to see if they agree, but having at least one person from qa/infra at a mid-cycle helps in small ways. At both I worked with folks to help them make more efficient use of their review time by exploring gerrit queries (there were people who didn't know this magic, nor did they think to ask until they saw some dashboards), at Neutron I gave my impromtu this-is-how-infra-testing-works in terms of the moving parts, and fortunately managed to work in a
Re: [openstack-dev] [all] Design Summit reloaded
On Wed, Aug 27, 2014 at 2:48 PM, Anita Kuno ante...@anteaya.info wrote: On 08/27/2014 02:46 PM, John Griffith wrote: On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco fla...@redhat.com wrote: On 08/27/2014 03:26 PM, Sean Dague wrote: On 08/27/2014 08:51 AM, Thierry Carrez wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. Day 2 and Day 3. Scheduled sessions for various programs That's our traditional scheduled space. We'll have a 33% less slots available. So, rather than trying to cover all the scope, the idea would be to focus those sessions on specific issues which really require face-to-face discussion (which can't be solved on the ML or using spec discussion) *or* require a lot of user feedback. That way, appearing in the general schedule is very helpful. This will require us to be a lot stricter on what we accept there and what we don't -- we won't have space for courtesy sessions anymore, and traditional/unnecessary sessions (like my traditional release schedule one) should just move to the mailing-list. Day 4. Contributors meetups On the last day, we could try to split the space so that we can conduct parallel midcycle-meetup-like contributors gatherings, with no time boundaries and an open agenda. Large projects could get a full day, smaller projects would get half a day (but could continue the discussion in a local bar). Ideally that meetup would end with some alignment on release goals, but the idea is to make the best of that time together to solve the issues you have. Friday would finish with the design summit feedback session, for those who are still around. I think this proposal makes the best use of our setup: discuss clear cross-project issues, address key specific topics which need face-to-face time and broader attendance, then try to replicate the success of midcycle meetup-like open unscheduled time to discuss whatever is hot at this point. There are still details to work out (is it possible split the space, should we use the usual design summit CFP website to organize the scheduled time...), but I would first like to have your feedback on this format. Also if you have alternative proposals that would make a better use of our 4 days, let me know. I definitely like this approach. I think it will be really interesting to collect feedback from people about the value they got from days 2 3 vs. Day 4. I also wonder if we should lose a slot from days 1 - 3 and expand the hallway time. Hallway track is always pretty interesting, and honestly at a lot of interesting ideas spring up. The 10 minute transitions often seem to feel like you are rushing between places too quickly some times. +1 Last summit, it was basically impossible to do any hallway talking and even meet some folks face-2-face. Other than that, I think the proposal is great and makes sense to me. Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Sounds like a great idea to me: +1 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I think this is a great direction. Here is my dilemma and it might just affect me. I attended 3 mid-cycles this release: one of Neutron's (there were 2), QA/Infra and Cinder. The Neutron and Cinder ones were mostly in pursuit of figuring out third party and exchanging information surrounding that (which I feel was successful). The QA/Infra one was, well even though I feel like I have been awol, I still consider this my home. From my perspective and check with Neutron and Cinder to see if they agree, but having at least one person from qa/infra at a mid-cycle helps in small ways. At both I worked with folks to help them make more efficient use of their review time by exploring gerrit queries (there were people who didn't know this magic, nor did
Re: [openstack-dev] [all] Design Summit reloaded
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
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
Excerpts from Anita Kuno's message of 2014-08-27 13:48:25 -0700: On 08/27/2014 02:46 PM, John Griffith wrote: On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco fla...@redhat.com wrote: On 08/27/2014 03:26 PM, Sean Dague wrote: On 08/27/2014 08:51 AM, Thierry Carrez wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. Day 2 and Day 3. Scheduled sessions for various programs That's our traditional scheduled space. We'll have a 33% less slots available. So, rather than trying to cover all the scope, the idea would be to focus those sessions on specific issues which really require face-to-face discussion (which can't be solved on the ML or using spec discussion) *or* require a lot of user feedback. That way, appearing in the general schedule is very helpful. This will require us to be a lot stricter on what we accept there and what we don't -- we won't have space for courtesy sessions anymore, and traditional/unnecessary sessions (like my traditional release schedule one) should just move to the mailing-list. Day 4. Contributors meetups On the last day, we could try to split the space so that we can conduct parallel midcycle-meetup-like contributors gatherings, with no time boundaries and an open agenda. Large projects could get a full day, smaller projects would get half a day (but could continue the discussion in a local bar). Ideally that meetup would end with some alignment on release goals, but the idea is to make the best of that time together to solve the issues you have. Friday would finish with the design summit feedback session, for those who are still around. I think this proposal makes the best use of our setup: discuss clear cross-project issues, address key specific topics which need face-to-face time and broader attendance, then try to replicate the success of midcycle meetup-like open unscheduled time to discuss whatever is hot at this point. There are still details to work out (is it possible split the space, should we use the usual design summit CFP website to organize the scheduled time...), but I would first like to have your feedback on this format. Also if you have alternative proposals that would make a better use of our 4 days, let me know. I definitely like this approach. I think it will be really interesting to collect feedback from people about the value they got from days 2 3 vs. Day 4. I also wonder if we should lose a slot from days 1 - 3 and expand the hallway time. Hallway track is always pretty interesting, and honestly at a lot of interesting ideas spring up. The 10 minute transitions often seem to feel like you are rushing between places too quickly some times. +1 Last summit, it was basically impossible to do any hallway talking and even meet some folks face-2-face. Other than that, I think the proposal is great and makes sense to me. Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Sounds like a great idea to me: +1 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I think this is a great direction. Here is my dilemma and it might just affect me. I attended 3 mid-cycles this release: one of Neutron's (there were 2), QA/Infra and Cinder. The Neutron and Cinder ones were mostly in pursuit of figuring out third party and exchanging information surrounding that (which I feel was successful). The QA/Infra one was, well even though I feel like I have been awol, I still consider this my home. From my perspective and check with Neutron and Cinder to see if they agree, but having at least one person from qa/infra at a mid-cycle helps in small ways. At both I worked with folks to help them make more efficient use of their review time by exploring gerrit queries (there were people who didn't know this magic, nor did they think to ask
Re: [openstack-dev] [all] Design Summit reloaded
On 08/27/2014 07:39 PM, Chris Jones wrote: Hi Anita Your impromptu infra-clue-dissemination talks sound interesting (I'd like to see the elastic recheck fingerprint one, for example). Would it make sense to amplify your reach, by making some short screencasts of these sorts of things? Cheers, -- Chris Jones /me sobs I tried to have that on my list a year ago and it kept getting shoved down. :( It isn't that I'm not capable, it is that I have little energy atm especially without a live audience. I'm also very picky about the editing (having worked in film). I don't have a timeline when I can say this would happen, at least from me. The knowledge isn't specific to me, if someone else is inclined. Thanks Chris, I appreciate the encouragement, Anita. On 27 Aug 2014, at 21:48, Anita Kuno ante...@anteaya.info wrote: On 08/27/2014 02:46 PM, John Griffith wrote: On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco fla...@redhat.com wrote: On 08/27/2014 03:26 PM, Sean Dague wrote: On 08/27/2014 08:51 AM, Thierry Carrez wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. Day 2 and Day 3. Scheduled sessions for various programs That's our traditional scheduled space. We'll have a 33% less slots available. So, rather than trying to cover all the scope, the idea would be to focus those sessions on specific issues which really require face-to-face discussion (which can't be solved on the ML or using spec discussion) *or* require a lot of user feedback. That way, appearing in the general schedule is very helpful. This will require us to be a lot stricter on what we accept there and what we don't -- we won't have space for courtesy sessions anymore, and traditional/unnecessary sessions (like my traditional release schedule one) should just move to the mailing-list. Day 4. Contributors meetups On the last day, we could try to split the space so that we can conduct parallel midcycle-meetup-like contributors gatherings, with no time boundaries and an open agenda. Large projects could get a full day, smaller projects would get half a day (but could continue the discussion in a local bar). Ideally that meetup would end with some alignment on release goals, but the idea is to make the best of that time together to solve the issues you have. Friday would finish with the design summit feedback session, for those who are still around. I think this proposal makes the best use of our setup: discuss clear cross-project issues, address key specific topics which need face-to-face time and broader attendance, then try to replicate the success of midcycle meetup-like open unscheduled time to discuss whatever is hot at this point. There are still details to work out (is it possible split the space, should we use the usual design summit CFP website to organize the scheduled time...), but I would first like to have your feedback on this format. Also if you have alternative proposals that would make a better use of our 4 days, let me know. I definitely like this approach. I think it will be really interesting to collect feedback from people about the value they got from days 2 3 vs. Day 4. I also wonder if we should lose a slot from days 1 - 3 and expand the hallway time. Hallway track is always pretty interesting, and honestly at a lot of interesting ideas spring up. The 10 minute transitions often seem to feel like you are rushing between places too quickly some times. +1 Last summit, it was basically impossible to do any hallway talking and even meet some folks face-2-face. Other than that, I think the proposal is great and makes sense to me. Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Sounds like a great idea to me: +1 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I think this is a great direction. Here is my dilemma and it might just affect me. I attended 3 mid-cycles
Re: [openstack-dev] [all] Design Summit reloaded
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
From: Chris Jones [mailto:c...@tenshu.net] Hi Anita Your impromptu infra-clue-dissemination talks sound interesting (I'd like to see the elastic recheck fingerprint one, for example). Would it make sense to amplify your reach, by making some short screencasts of these sorts of things? Cheers, -- Chris Jones [Rocky Grober] +1 or a session at Paris that is recorded? On 27 Aug 2014, at 21:48, Anita Kuno ante...@anteaya.info wrote: On 08/27/2014 02:46 PM, John Griffith wrote: On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco fla...@redhat.com wrote: On 08/27/2014 03:26 PM, Sean Dague wrote: On 08/27/2014 08:51 AM, Thierry Carrez wrote: Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time). Here is something we could do: Day 1. Cross-project sessions / incubated projects / other projects I think that worked well last time. 3 parallel rooms where we can address top cross-project questions, discuss the results of the various experiments we conducted during juno. Don't hesitate to schedule 2 slots for discussions, so that we have time to come to the bottom of those issues. Incubated projects (and maybe other projects, if space allows) occupy the remaining space on day 1, and could occupy pods on the other days. Day 2 and Day 3. Scheduled sessions for various programs That's our traditional scheduled space. We'll have a 33% less slots available. So, rather than trying to cover all the scope, the idea would be to focus those sessions on specific issues which really require face-to-face discussion (which can't be solved on the ML or using spec discussion) *or* require a lot of user feedback. That way, appearing in the general schedule is very helpful. This will require us to be a lot stricter on what we accept there and what we don't -- we won't have space for courtesy sessions anymore, and traditional/unnecessary sessions (like my traditional release schedule one) should just move to the mailing-list. Day 4. Contributors meetups On the last day, we could try to split the space so that we can conduct parallel midcycle-meetup-like contributors gatherings, with no time boundaries and an open agenda. Large projects could get a full day, smaller projects would get half a day (but could continue the discussion in a local bar). Ideally that meetup would end with some alignment on release goals, but the idea is to make the best of that time together to solve the issues you have. Friday would finish with the design summit feedback session, for those who are still around. I think this proposal makes the best use of our setup: discuss clear cross-project issues, address key specific topics which need face-to-face time and broader attendance, then try to replicate the success of midcycle meetup-like open unscheduled time to discuss whatever is hot at this point. There are still details to work out (is it possible split the space, should we use the usual design summit CFP website to organize the scheduled time...), but I would first like to have your feedback on this format. Also if you have alternative proposals that would make a better use of our 4 days, let me know. I definitely like this approach. I think it will be really interesting to collect feedback from people about the value they got from days 2 3 vs. Day 4. I also wonder if we should lose a slot from days 1 - 3 and expand the hallway time. Hallway track is always pretty interesting, and honestly at a lot of interesting ideas spring up. The 10 minute transitions often seem to feel like you are rushing between places too quickly some times. +1 Last summit, it was basically impossible to do any hallway talking and even meet some folks face-2-face. Other than that, I think the proposal is great and makes sense to me. Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Sounds like a great idea to me: +1 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I think this is a great direction. Here is my dilemma and it might just affect me. I attended 3 mid-cycles this release: one of Neutron's (there were 2), QA/Infra and Cinder. The Neutron and Cinder ones were mostly in pursuit of figuring out third party and exchanging information surrounding that (which I feel was successful). The QA/Infra one was, well even though I feel like I have been awol, I still consider this my home. From my perspective and check with Neutron
