Open Stack

Excerpts from Thierry Carrez's message of 2017-03-10 17:04:54 +0100:
> Ben Swartzlander wrote:
> > On 03/09/2017 12:10 PM, Jonathan Bryce wrote:
> >> Putting that aside, I appreciate your providing your input. The most
> >> consistent piece of feedback we received was around scheduling and
> >> visibility for sessions, so I think that is definitely an area for
> >> improvement at the next PTG. I heard mixed feedback on whether the
> >> ability to participate in multiple projects was better or worse than
> >> under the previous model, but understanding common conflicts ahead of
> >> time might give us a chance to schedule in a way that makes the
> >> multi-project work more possible. Did you participate in both Cinder
> >> and Manila mid-cycles in addition to the Design Summit sessions
> >> previously? Trying to understand which types of specific interactions
> >> you’re now less able to participate in.
> > 
> > Yes in the past I was able to attend all of the Manila and most of the
> > Cinder sessions at the Design summit, and I was able to attend the
> > Cinder midcycles in person and (since I'm the PTL) I was able to
> > schedule the Manila midcycles to not conflict.
> 
> On that particular bit of feedback ("making it impossible to participate
> in 2 or more vertical projects") it is feedback that I definitely heard :)
> 
> While the event structure made it generally a lot easier to tap into
> other teams (and a *lot* of them did just that), the horizontal/vertical
> split definitely made it more difficult for Manila folks to attend all
> Cinder sessions, or for Storlets folks to attend all Swift sessions. On
> a personal note, it made it more difficult for *me* to attend all
> Architecture WG and Stewardship workgroup and Release Team and Infra
> sessions, which were all going on at the same time on Monday/Tuesday. So
> it's not something that only affected vertical projects.
> 
> We can definitely improve on that, and come up with a more... creative
> way to split usage of rooms than a pretty-arbitrary grouping of projects
> into "vertical" and "horizontal" groups. There is no miracle solution
> (there will always be someone needing to be in two places at the same
> time), but the strawman split we tried for the first one is certainly
> not the optimal solution. If you have suggestions on how we can better
> map room/days, I'm all ears. I was thinking about taking input on major
> team overlaps (like the one you pointed to between Manila and Cinder) as
> a first step, and try to come up with a magic formula that would
> minimize conflicts.
> 

For those who didn't ever use it, attendees to UDS (Ubuntu Dev Summit)
would mark themselves as interested or required for sessions (in the
Launchpad blueprint system), and would express which days they'd be
at the summit.  Then a scheduling program would automatically generate
schedules with the least amount of conflicts.

I'm not saying we should copy summit's model, or (noooooooooo) use the
actual Summit django app[1]. But we _could_ use a similar algorithm,
except have project teams, instead of individuals, as the attendees,
perhaps splitting liasons/tc members/etc. off as their own groups,
and then at least have an optimal schedule generated.

A few summary points about UDS for those interested (tl;dr - It's not perfect)

 * UDS also wanted everyone to move around in the hallways every hour or
   so. There was a desire to _not_ let people "camp out" in one room. As
   a person who thrives in the bustling hallways, I like that. But those
   who need a quieter room to build confidence, and a more parliamentary
   procedure to get their voice heard are penalized. Also PTG is for
   focused hacking time too, but that could be solved by having large
   blocks for focus/pairing/etc time.

 * Running the summit scheduler in real-time as sessions and attendees
   were added created _unbelievable chaos_. There was almost always
   somebody cursing at the summit schedule screens as their most important
   session was moved to a small room, double-booked, or moved to a day
   they weren't going to be there. In my 7 or so UDS's, I think we only
   tried that for 2 of them before it was locked down the week before UDS.

 * Not running the summit scheduler in real-time meant that added
   sessions and new attendees were at a disadvantage and had to manually
   try to coordinate with the free space on the schedule. Since the
   schedule was tuned to the more static attendee base and set of
   sessions, this usually meant that the hotel bar after sessions was
   the more reliable place to have a discussion that wasn't expected.

[1] https://launchpad.net/summit