Re: [openstack-dev] Vancouver Design Summit format changes
I think that how Docs handles these changes depends largely on whether or not we're given a track. I'm aware that we didn't get one in Paris, and as a consequence a lot of my team felt it was difficult to get any real work done. Like Sean, I appreciate that it's a difficult decision, but am looking forward to hearing how the TC plan to make this choice. Lana On 10/01/15 03:06, sean roberts wrote: I like it. Thank you for coming up with improvements to the summit planning. One caveat on the definition of project for summit space. Which projects get considered for space is always difficult. Who is going to fill the rooms they request or are they going to have them mostly empty? I'm sure the TC can figure it out by looking at the number of contributors or something like that. I would however, like to know a bit more of your plan for this specific part of the proposal sooner than later. On Friday, January 9, 2015, Thierry Carrez thie...@openstack.org javascript:_e(%7B%7D,'cvml','thie...@openstack.org'); wrote: Hi everyone, The OpenStack Foundation staff is considering a number of changes to the Design Summit format for Vancouver, changes on which we'd very much like to hear your feedback. The problems we are trying to solve are the following: - Accommodate the needs of more OpenStack projects - Reduce separation and perceived differences between the Ops Summit and the Design/Dev Summit - Create calm and less-crowded spaces for teams to gather and get more work done While some sessions benefit from large exposure, loads of feedback and large rooms, some others are just workgroup-oriented work sessions that benefit from smaller rooms, less exposure and more whiteboards. Smaller rooms are also cheaper space-wise, so they allow us to scale more easily to a higher number of OpenStack projects. My proposal is the following. Each project team would have a track at the Design Summit. Ops feedback is in my opinion part of the design of OpenStack, so the Ops Summit would become a track within the forward-looking Design Summit. Tracks may use two separate types of sessions: * Fishbowl sessions Those sessions are for open discussions where a lot of participation and feedback is desirable. Those would happen in large rooms (100 to 300 people, organized in fishbowl style with a projector). Those would have catchy titles and appear on the general Design Summit schedule. We would have space for 6 or 7 of those in parallel during the first 3 days of the Design Summit (we would not run them on Friday, to reproduce the successful Friday format we had in Paris). * Working sessions Those sessions are for a smaller group of contributors to get specific work done or prioritized. Those would happen in smaller rooms (20 to 40 people, organized in boardroom style with loads of whiteboards). Those would have a blanket title (like infra team working session) and redirect to an etherpad for more precise and current content, which should limit out-of-team participation. Those would replace project pods. We would have space for 10 to 12 of those in parallel for the first 3 days, and 18 to 20 of those in parallel on the Friday (by reusing fishbowl rooms). Each project track would request some mix of sessions (We'd like 4 fishbowl sessions, 8 working sessions on Tue-Thu + half a day on Friday) and the TC would arbitrate how to allocate the limited resources. Agenda for the fishbowl sessions would need to be published in advance, but agenda for the working sessions could be decided dynamically from an etherpad agenda. By making larger use of smaller spaces, we expect that setup to let us accommodate the needs of more projects. By merging the two separate Ops Summit and Design Summit events, it should make the Ops feedback an integral part of the Design process rather than a second-class citizen. By creating separate working session rooms, we hope to evolve the pod concept into something where it's easier for teams to get work done (less noise, more whiteboards, clearer agenda). What do you think ? Could that work ? If not, do you have alternate suggestions ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- ~sean ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Lana Brindley Technical Writer Rackspace Cloud Builders Australia http://lanabrindley.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] Vancouver Design Summit format changes
On 09/01/15 15:50 +0100, Thierry Carrez wrote: [huge snip] What do you think ? Could that work ? If not, do you have alternate suggestions ? Love it! Thanks for the thoughtful and detailed email. Flavio -- @flaper87 Flavio Percoco pgp2LB9GMnSpn.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Vancouver Design Summit format changes
Tim Bell wrote: Let's ask the operators opinions too on openstack-operators mailing list. Sure, that's my next step. I first wanted to check that this change was fine for historic Design Summit participants. I'll follow up with operators and also discuss it at the Ops meetup. FWIW, the proposed format is partly inspired by the recent Ops Summit (with its single general session and multiple workgroup sessions), so I don't expect the new format to be a surprise there. I agree there is a significant scheduling challenge that we still need to solve (in all cases), but the format itself should be fine. Grouping the two events into one is also about facilitating exchanges and sharing the same space and lunches -- further closing the feedback loop. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Vancouver Design Summit format changes
On Fri, Jan 9, 2015 at 8:50 AM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, The OpenStack Foundation staff is considering a number of changes to the Design Summit format for Vancouver, changes on which we'd very much like to hear your feedback. The problems we are trying to solve are the following: - Accommodate the needs of more OpenStack projects - Reduce separation and perceived differences between the Ops Summit and the Design/Dev Summit - Create calm and less-crowded spaces for teams to gather and get more work done While some sessions benefit from large exposure, loads of feedback and large rooms, some others are just workgroup-oriented work sessions that benefit from smaller rooms, less exposure and more whiteboards. Smaller rooms are also cheaper space-wise, so they allow us to scale more easily to a higher number of OpenStack projects. My proposal is the following. Each project team would have a track at the Design Summit. Ops feedback is in my opinion part of the design of OpenStack, so the Ops Summit would become a track within the forward-looking Design Summit. Tracks may use two separate types of sessions: * Fishbowl sessions Those sessions are for open discussions where a lot of participation and feedback is desirable. Those would happen in large rooms (100 to 300 people, organized in fishbowl style with a projector). Those would have catchy titles and appear on the general Design Summit schedule. We would have space for 6 or 7 of those in parallel during the first 3 days of the Design Summit (we would not run them on Friday, to reproduce the successful Friday format we had in Paris). * Working sessions Those sessions are for a smaller group of contributors to get specific work done or prioritized. Those would happen in smaller rooms (20 to 40 people, organized in boardroom style with loads of whiteboards). Those would have a blanket title (like infra team working session) and redirect to an etherpad for more precise and current content, which should limit out-of-team participation. Those would replace project pods. We would have space for 10 to 12 of those in parallel for the first 3 days, and 18 to 20 of those in parallel on the Friday (by reusing fishbowl rooms). Each project track would request some mix of sessions (We'd like 4 fishbowl sessions, 8 working sessions on Tue-Thu + half a day on Friday) and the TC would arbitrate how to allocate the limited resources. Agenda for the fishbowl sessions would need to be published in advance, but agenda for the working sessions could be decided dynamically from an etherpad agenda. By making larger use of smaller spaces, we expect that setup to let us accommodate the needs of more projects. By merging the two separate Ops Summit and Design Summit events, it should make the Ops feedback an integral part of the Design process rather than a second-class citizen. By creating separate working session rooms, we hope to evolve the pod concept into something where it's easier for teams to get work done (less noise, more whiteboards, clearer agenda). What do you think ? Could that work ? If not, do you have alternate suggestions ? This looks great, thanks for continuing to evolve the Summit format! Kyle -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Vancouver Design Summit format changes
On 10/01/15 03:26, Michael Dorman wrote: (X-posted to -operators.) Any thoughts on how the ops track spaces would be requested, since there is not a real ‘operators project’, PTL, etc.? Based on our past events and summit survey feedback from Paris, I've mentioned to Thierry that we probably need at least: 3 large rooms * 1 day's worth of slots each (for general sessions) 3 small rooms * 1 day's worth of slots each (for working groups) The content for these should, as Tim mentions, be chosen by discussion. Previously, etherpad and ops-ml has worked well for us, but open to other ideas! In terms of the actual scheduling, I think it makes sense to have the 'general sessions' scheduled in a block so you can find them easily and just stay there all day. The working group sessions are probably of more specialised interest and distributing them throughout the week could actually help people get to more of them compared to running them in parallel as we did in Paris. I assume this would come from the operators group as a whole, so probably something we should put on the agenda at the ops meet up in March. (I’ve added it to the etherpad.) Mike On 1/9/15, 2:50 PM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, The OpenStack Foundation staff is considering a number of changes to the Design Summit format for Vancouver, changes on which we'd very much like to hear your feedback. The problems we are trying to solve are the following: - Accommodate the needs of more OpenStack projects - Reduce separation and perceived differences between the Ops Summit and the Design/Dev Summit - Create calm and less-crowded spaces for teams to gather and get more work done While some sessions benefit from large exposure, loads of feedback and large rooms, some others are just workgroup-oriented work sessions that benefit from smaller rooms, less exposure and more whiteboards. Smaller rooms are also cheaper space-wise, so they allow us to scale more easily to a higher number of OpenStack projects. My proposal is the following. Each project team would have a track at the Design Summit. Ops feedback is in my opinion part of the design of OpenStack, so the Ops Summit would become a track within the forward-looking Design Summit. Tracks may use two separate types of sessions: * Fishbowl sessions Those sessions are for open discussions where a lot of participation and feedback is desirable. Those would happen in large rooms (100 to 300 people, organized in fishbowl style with a projector). Those would have catchy titles and appear on the general Design Summit schedule. We would have space for 6 or 7 of those in parallel during the first 3 days of the Design Summit (we would not run them on Friday, to reproduce the successful Friday format we had in Paris). * Working sessions Those sessions are for a smaller group of contributors to get specific work done or prioritized. Those would happen in smaller rooms (20 to 40 people, organized in boardroom style with loads of whiteboards). Those would have a blanket title (like infra team working session) and redirect to an etherpad for more precise and current content, which should limit out-of-team participation. Those would replace project pods. We would have space for 10 to 12 of those in parallel for the first 3 days, and 18 to 20 of those in parallel on the Friday (by reusing fishbowl rooms). Each project track would request some mix of sessions (We'd like 4 fishbowl sessions, 8 working sessions on Tue-Thu + half a day on Friday) and the TC would arbitrate how to allocate the limited resources. Agenda for the fishbowl sessions would need to be published in advance, but agenda for the working sessions could be decided dynamically from an etherpad agenda. By making larger use of smaller spaces, we expect that setup to let us accommodate the needs of more projects. By merging the two separate Ops Summit and Design Summit events, it should make the Ops feedback an integral part of the Design process rather than a second-class citizen. By creating separate working session rooms, we hope to evolve the pod concept into something where it's easier for teams to get work done (less noise, more whiteboards, clearer agenda). What do you think ? Could that work ? If not, do you have alternate suggestions ? -- 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] Vancouver Design Summit format changes
On 15:50 Fri 09 Jan , Thierry Carrez wrote: Hi everyone, The OpenStack Foundation staff is considering a number of changes to the Design Summit format for Vancouver, changes on which we'd very much like to hear your feedback. The problems we are trying to solve are the following: - Accommodate the needs of more OpenStack projects - Reduce separation and perceived differences between the Ops Summit and the Design/Dev Summit - Create calm and less-crowded spaces for teams to gather and get more work done While some sessions benefit from large exposure, loads of feedback and large rooms, some others are just workgroup-oriented work sessions that benefit from smaller rooms, less exposure and more whiteboards. Smaller rooms are also cheaper space-wise, so they allow us to scale more easily to a higher number of OpenStack projects. My proposal is the following. Each project team would have a track at the Design Summit. Ops feedback is in my opinion part of the design of OpenStack, so the Ops Summit would become a track within the forward-looking Design Summit. Tracks may use two separate types of sessions: * Fishbowl sessions Those sessions are for open discussions where a lot of participation and feedback is desirable. Those would happen in large rooms (100 to 300 people, organized in fishbowl style with a projector). Those would have catchy titles and appear on the general Design Summit schedule. We would have space for 6 or 7 of those in parallel during the first 3 days of the Design Summit (we would not run them on Friday, to reproduce the successful Friday format we had in Paris). * Working sessions Those sessions are for a smaller group of contributors to get specific work done or prioritized. Those would happen in smaller rooms (20 to 40 people, organized in boardroom style with loads of whiteboards). Those would have a blanket title (like infra team working session) and redirect to an etherpad for more precise and current content, which should limit out-of-team participation. Those would replace project pods. We would have space for 10 to 12 of those in parallel for the first 3 days, and 18 to 20 of those in parallel on the Friday (by reusing fishbowl rooms). Each project track would request some mix of sessions (We'd like 4 fishbowl sessions, 8 working sessions on Tue-Thu + half a day on Friday) and the TC would arbitrate how to allocate the limited resources. Agenda for the fishbowl sessions would need to be published in advance, but agenda for the working sessions could be decided dynamically from an etherpad agenda. By making larger use of smaller spaces, we expect that setup to let us accommodate the needs of more projects. By merging the two separate Ops Summit and Design Summit events, it should make the Ops feedback an integral part of the Design process rather than a second-class citizen. By creating separate working session rooms, we hope to evolve the pod concept into something where it's easier for teams to get work done (less noise, more whiteboards, clearer agenda). What do you think ? Could that work ? If not, do you have alternate suggestions ? Sounds good to me. Glad we're keeping the Friday format too! -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Vancouver Design Summit format changes
On 01/09/2015 09:50 AM, Thierry Carrez wrote: What do you think ? Could that work ? If not, do you have alternate suggestions ? This seems incorporate more of what people have found incredibly useful (work sessions) and organizes things in a way to accommodate the anticipated growth in projects this cycle. I think this suggestion sounds like a very nice iteration on the design summit format. Nice work! -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Vancouver Design Summit format changes
Let's ask the operators opinions too on openstack-operators mailing list. There was some duplication during the summit between the tracks but there is also a significant operator need outside the pure code area which comes along with the big tent tagging for projects. We need to make sure that we reserve time for focus on operator needs for - Packaging - Monitoring - Automation - Configuration - … These are areas which are not pure code development and deliverables in the classic OpenStack project sense but are pre-reqs for any production deployment. The cells and nova-network to Neutron migration sessions were good examples of how we can agree on the best way forward with shared effort. For me, the key part is making sure the right combinations of people are available in the right sessions (and ideally key topics are discussed in unique sessions). I think we're getting very close as we've been doing much mutual design in the past couple of summits/mid-cycle meet ups and subsequent *-specs reviews. Tim On 9 Jan 2015, at 18:57, Jay Pipes jaypi...@gmail.com wrote: Huge +1 from me. Thank you, Thierry. -jay On 01/09/2015 09:50 AM, Thierry Carrez wrote: Hi everyone, The OpenStack Foundation staff is considering a number of changes to the Design Summit format for Vancouver, changes on which we'd very much like to hear your feedback. The problems we are trying to solve are the following: - Accommodate the needs of more OpenStack projects - Reduce separation and perceived differences between the Ops Summit and the Design/Dev Summit - Create calm and less-crowded spaces for teams to gather and get more work done While some sessions benefit from large exposure, loads of feedback and large rooms, some others are just workgroup-oriented work sessions that benefit from smaller rooms, less exposure and more whiteboards. Smaller rooms are also cheaper space-wise, so they allow us to scale more easily to a higher number of OpenStack projects. My proposal is the following. Each project team would have a track at the Design Summit. Ops feedback is in my opinion part of the design of OpenStack, so the Ops Summit would become a track within the forward-looking Design Summit. Tracks may use two separate types of sessions: * Fishbowl sessions Those sessions are for open discussions where a lot of participation and feedback is desirable. Those would happen in large rooms (100 to 300 people, organized in fishbowl style with a projector). Those would have catchy titles and appear on the general Design Summit schedule. We would have space for 6 or 7 of those in parallel during the first 3 days of the Design Summit (we would not run them on Friday, to reproduce the successful Friday format we had in Paris). * Working sessions Those sessions are for a smaller group of contributors to get specific work done or prioritized. Those would happen in smaller rooms (20 to 40 people, organized in boardroom style with loads of whiteboards). Those would have a blanket title (like infra team working session) and redirect to an etherpad for more precise and current content, which should limit out-of-team participation. Those would replace project pods. We would have space for 10 to 12 of those in parallel for the first 3 days, and 18 to 20 of those in parallel on the Friday (by reusing fishbowl rooms). Each project track would request some mix of sessions (We'd like 4 fishbowl sessions, 8 working sessions on Tue-Thu + half a day on Friday) and the TC would arbitrate how to allocate the limited resources. Agenda for the fishbowl sessions would need to be published in advance, but agenda for the working sessions could be decided dynamically from an etherpad agenda. By making larger use of smaller spaces, we expect that setup to let us accommodate the needs of more projects. By merging the two separate Ops Summit and Design Summit events, it should make the Ops feedback an integral part of the Design process rather than a second-class citizen. By creating separate working session rooms, we hope to evolve the pod concept into something where it's easier for teams to get work done (less noise, more whiteboards, clearer agenda). What do you think ? Could that work ? If not, do you have alternate suggestions ? ___ 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] Vancouver Design Summit format changes
Inline ~sean On Jan 9, 2015, at 9:30 AM, Thierry Carrez thie...@openstack.org wrote: sean roberts wrote: I like it. Thank you for coming up with improvements to the summit planning. One caveat on the definition of project for summit space. Which projects get considered for space is always difficult. Who is going to fill the rooms they request or are they going to have them mostly empty? I'm sure the TC can figure it out by looking at the number of contributors or something like that. I would however, like to know a bit more of your plan for this specific part of the proposal sooner than later. That would be any OpenStack project, with the project structure reform hopefully completed by then. That would likely let projects that were previously in the other projects track have time to apply and to be considered full Design Summit citizens. The presence of a busy other projects track to cover for unofficial projects in previous summits really was an early sign that something was wrong with our definition of OpenStack projects anyway :) Got it. This is going in the right direction. Now I expect the TC to split the limited resources following metrics like team size and development activity. Small projects might end up having just a couple sessions in mostly-empty rooms, yes... still better than not giving space at all. Agreed. I don't want to starve innovation at the summits. -- 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] Vancouver Design Summit format changes
(X-posted to -operators.) Any thoughts on how the ops track spaces would be requested, since there is not a real ‘operators project’, PTL, etc.? I assume this would come from the operators group as a whole, so probably something we should put on the agenda at the ops meet up in March. (I’ve added it to the etherpad.) Mike On 1/9/15, 2:50 PM, Thierry Carrez thie...@openstack.org wrote: Hi everyone, The OpenStack Foundation staff is considering a number of changes to the Design Summit format for Vancouver, changes on which we'd very much like to hear your feedback. The problems we are trying to solve are the following: - Accommodate the needs of more OpenStack projects - Reduce separation and perceived differences between the Ops Summit and the Design/Dev Summit - Create calm and less-crowded spaces for teams to gather and get more work done While some sessions benefit from large exposure, loads of feedback and large rooms, some others are just workgroup-oriented work sessions that benefit from smaller rooms, less exposure and more whiteboards. Smaller rooms are also cheaper space-wise, so they allow us to scale more easily to a higher number of OpenStack projects. My proposal is the following. Each project team would have a track at the Design Summit. Ops feedback is in my opinion part of the design of OpenStack, so the Ops Summit would become a track within the forward-looking Design Summit. Tracks may use two separate types of sessions: * Fishbowl sessions Those sessions are for open discussions where a lot of participation and feedback is desirable. Those would happen in large rooms (100 to 300 people, organized in fishbowl style with a projector). Those would have catchy titles and appear on the general Design Summit schedule. We would have space for 6 or 7 of those in parallel during the first 3 days of the Design Summit (we would not run them on Friday, to reproduce the successful Friday format we had in Paris). * Working sessions Those sessions are for a smaller group of contributors to get specific work done or prioritized. Those would happen in smaller rooms (20 to 40 people, organized in boardroom style with loads of whiteboards). Those would have a blanket title (like infra team working session) and redirect to an etherpad for more precise and current content, which should limit out-of-team participation. Those would replace project pods. We would have space for 10 to 12 of those in parallel for the first 3 days, and 18 to 20 of those in parallel on the Friday (by reusing fishbowl rooms). Each project track would request some mix of sessions (We'd like 4 fishbowl sessions, 8 working sessions on Tue-Thu + half a day on Friday) and the TC would arbitrate how to allocate the limited resources. Agenda for the fishbowl sessions would need to be published in advance, but agenda for the working sessions could be decided dynamically from an etherpad agenda. By making larger use of smaller spaces, we expect that setup to let us accommodate the needs of more projects. By merging the two separate Ops Summit and Design Summit events, it should make the Ops feedback an integral part of the Design process rather than a second-class citizen. By creating separate working session rooms, we hope to evolve the pod concept into something where it's easier for teams to get work done (less noise, more whiteboards, clearer agenda). What do you think ? Could that work ? If not, do you have alternate suggestions ? -- 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
[openstack-dev] Vancouver Design Summit format changes
I like it. Thank you for coming up with improvements to the summit planning. One caveat on the definition of project for summit space. Which projects get considered for space is always difficult. Who is going to fill the rooms they request or are they going to have them mostly empty? I'm sure the TC can figure it out by looking at the number of contributors or something like that. I would however, like to know a bit more of your plan for this specific part of the proposal sooner than later. On Friday, January 9, 2015, Thierry Carrez thie...@openstack.org javascript:_e(%7B%7D,'cvml','thie...@openstack.org'); wrote: Hi everyone, The OpenStack Foundation staff is considering a number of changes to the Design Summit format for Vancouver, changes on which we'd very much like to hear your feedback. The problems we are trying to solve are the following: - Accommodate the needs of more OpenStack projects - Reduce separation and perceived differences between the Ops Summit and the Design/Dev Summit - Create calm and less-crowded spaces for teams to gather and get more work done While some sessions benefit from large exposure, loads of feedback and large rooms, some others are just workgroup-oriented work sessions that benefit from smaller rooms, less exposure and more whiteboards. Smaller rooms are also cheaper space-wise, so they allow us to scale more easily to a higher number of OpenStack projects. My proposal is the following. Each project team would have a track at the Design Summit. Ops feedback is in my opinion part of the design of OpenStack, so the Ops Summit would become a track within the forward-looking Design Summit. Tracks may use two separate types of sessions: * Fishbowl sessions Those sessions are for open discussions where a lot of participation and feedback is desirable. Those would happen in large rooms (100 to 300 people, organized in fishbowl style with a projector). Those would have catchy titles and appear on the general Design Summit schedule. We would have space for 6 or 7 of those in parallel during the first 3 days of the Design Summit (we would not run them on Friday, to reproduce the successful Friday format we had in Paris). * Working sessions Those sessions are for a smaller group of contributors to get specific work done or prioritized. Those would happen in smaller rooms (20 to 40 people, organized in boardroom style with loads of whiteboards). Those would have a blanket title (like infra team working session) and redirect to an etherpad for more precise and current content, which should limit out-of-team participation. Those would replace project pods. We would have space for 10 to 12 of those in parallel for the first 3 days, and 18 to 20 of those in parallel on the Friday (by reusing fishbowl rooms). Each project track would request some mix of sessions (We'd like 4 fishbowl sessions, 8 working sessions on Tue-Thu + half a day on Friday) and the TC would arbitrate how to allocate the limited resources. Agenda for the fishbowl sessions would need to be published in advance, but agenda for the working sessions could be decided dynamically from an etherpad agenda. By making larger use of smaller spaces, we expect that setup to let us accommodate the needs of more projects. By merging the two separate Ops Summit and Design Summit events, it should make the Ops feedback an integral part of the Design process rather than a second-class citizen. By creating separate working session rooms, we hope to evolve the pod concept into something where it's easier for teams to get work done (less noise, more whiteboards, clearer agenda). What do you think ? Could that work ? If not, do you have alternate suggestions ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- ~sean ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Vancouver Design Summit format changes
sean roberts wrote: I like it. Thank you for coming up with improvements to the summit planning. One caveat on the definition of project for summit space. Which projects get considered for space is always difficult. Who is going to fill the rooms they request or are they going to have them mostly empty? I'm sure the TC can figure it out by looking at the number of contributors or something like that. I would however, like to know a bit more of your plan for this specific part of the proposal sooner than later. That would be any OpenStack project, with the project structure reform hopefully completed by then. That would likely let projects that were previously in the other projects track have time to apply and to be considered full Design Summit citizens. The presence of a busy other projects track to cover for unofficial projects in previous summits really was an early sign that something was wrong with our definition of OpenStack projects anyway :) Now I expect the TC to split the limited resources following metrics like team size and development activity. Small projects might end up having just a couple sessions in mostly-empty rooms, yes... still better than not giving space at all. -- 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] Vancouver Design Summit format changes
Huge +1 from me. Thank you, Thierry. -jay On 01/09/2015 09:50 AM, Thierry Carrez wrote: Hi everyone, The OpenStack Foundation staff is considering a number of changes to the Design Summit format for Vancouver, changes on which we'd very much like to hear your feedback. The problems we are trying to solve are the following: - Accommodate the needs of more OpenStack projects - Reduce separation and perceived differences between the Ops Summit and the Design/Dev Summit - Create calm and less-crowded spaces for teams to gather and get more work done While some sessions benefit from large exposure, loads of feedback and large rooms, some others are just workgroup-oriented work sessions that benefit from smaller rooms, less exposure and more whiteboards. Smaller rooms are also cheaper space-wise, so they allow us to scale more easily to a higher number of OpenStack projects. My proposal is the following. Each project team would have a track at the Design Summit. Ops feedback is in my opinion part of the design of OpenStack, so the Ops Summit would become a track within the forward-looking Design Summit. Tracks may use two separate types of sessions: * Fishbowl sessions Those sessions are for open discussions where a lot of participation and feedback is desirable. Those would happen in large rooms (100 to 300 people, organized in fishbowl style with a projector). Those would have catchy titles and appear on the general Design Summit schedule. We would have space for 6 or 7 of those in parallel during the first 3 days of the Design Summit (we would not run them on Friday, to reproduce the successful Friday format we had in Paris). * Working sessions Those sessions are for a smaller group of contributors to get specific work done or prioritized. Those would happen in smaller rooms (20 to 40 people, organized in boardroom style with loads of whiteboards). Those would have a blanket title (like infra team working session) and redirect to an etherpad for more precise and current content, which should limit out-of-team participation. Those would replace project pods. We would have space for 10 to 12 of those in parallel for the first 3 days, and 18 to 20 of those in parallel on the Friday (by reusing fishbowl rooms). Each project track would request some mix of sessions (We'd like 4 fishbowl sessions, 8 working sessions on Tue-Thu + half a day on Friday) and the TC would arbitrate how to allocate the limited resources. Agenda for the fishbowl sessions would need to be published in advance, but agenda for the working sessions could be decided dynamically from an etherpad agenda. By making larger use of smaller spaces, we expect that setup to let us accommodate the needs of more projects. By merging the two separate Ops Summit and Design Summit events, it should make the Ops feedback an integral part of the Design process rather than a second-class citizen. By creating separate working session rooms, we hope to evolve the pod concept into something where it's easier for teams to get work done (less noise, more whiteboards, clearer agenda). What do you think ? Could that work ? If not, do you have alternate suggestions ? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Vancouver Design Summit format changes
Hi everyone, The OpenStack Foundation staff is considering a number of changes to the Design Summit format for Vancouver, changes on which we'd very much like to hear your feedback. The problems we are trying to solve are the following: - Accommodate the needs of more OpenStack projects - Reduce separation and perceived differences between the Ops Summit and the Design/Dev Summit - Create calm and less-crowded spaces for teams to gather and get more work done While some sessions benefit from large exposure, loads of feedback and large rooms, some others are just workgroup-oriented work sessions that benefit from smaller rooms, less exposure and more whiteboards. Smaller rooms are also cheaper space-wise, so they allow us to scale more easily to a higher number of OpenStack projects. My proposal is the following. Each project team would have a track at the Design Summit. Ops feedback is in my opinion part of the design of OpenStack, so the Ops Summit would become a track within the forward-looking Design Summit. Tracks may use two separate types of sessions: * Fishbowl sessions Those sessions are for open discussions where a lot of participation and feedback is desirable. Those would happen in large rooms (100 to 300 people, organized in fishbowl style with a projector). Those would have catchy titles and appear on the general Design Summit schedule. We would have space for 6 or 7 of those in parallel during the first 3 days of the Design Summit (we would not run them on Friday, to reproduce the successful Friday format we had in Paris). * Working sessions Those sessions are for a smaller group of contributors to get specific work done or prioritized. Those would happen in smaller rooms (20 to 40 people, organized in boardroom style with loads of whiteboards). Those would have a blanket title (like infra team working session) and redirect to an etherpad for more precise and current content, which should limit out-of-team participation. Those would replace project pods. We would have space for 10 to 12 of those in parallel for the first 3 days, and 18 to 20 of those in parallel on the Friday (by reusing fishbowl rooms). Each project track would request some mix of sessions (We'd like 4 fishbowl sessions, 8 working sessions on Tue-Thu + half a day on Friday) and the TC would arbitrate how to allocate the limited resources. Agenda for the fishbowl sessions would need to be published in advance, but agenda for the working sessions could be decided dynamically from an etherpad agenda. By making larger use of smaller spaces, we expect that setup to let us accommodate the needs of more projects. By merging the two separate Ops Summit and Design Summit events, it should make the Ops feedback an integral part of the Design process rather than a second-class citizen. By creating separate working session rooms, we hope to evolve the pod concept into something where it's easier for teams to get work done (less noise, more whiteboards, clearer agenda). What do you think ? Could that work ? If not, do you have alternate suggestions ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
