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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
