Open Stack

Hi again,

For the PTG events we have, by design, a pretty loose schedule. Each
room is free to organize their agenda in whatever way they see fit, and
take breaks whenever they need. This flexibility is key to keep our
productivity at those events at a maximum. In Atlanta, most teams ended
up dynamically building a loose agenda on a room etherpad.

This approach is optimized for team meetups and people who strongly
identify with one team in particular. In Atlanta during the first two
days, where a lot of vertical team contributors did not really know
which room to go to, it was very difficult to get a feel of what is
currently being discussed and where they could go. Looking into 20
etherpads and trying to figure out what is currently being discussed is
just not practical. In the feedback we received, the need to expose the
schedule more visibly was the #1 request.

It is a thin line to walk on. We clearly don't want to publish a
schedule in advance or be tied to pre-established timeboxes for every
topic. We want it to be pretty fluid and natural, but we still need to
somehow make "what's currently happening" (and "what will be discussed
next") emerge globally.

One lightweight solution I've been working on is an IRC bot ("ptgbot")
that would produce a static webpage. Room leaders would update it on
#openstack-ptg using commands like:

#swift now discussing ring placement optimizations
#swift next at 14:00 we plan to discuss better #keystone integration

and the bot would collect all those "now" and "next" items and publish a
single (mobile-friendly) webpage, (which would also include
ethercalc-scheduled things, if we keep any).

The IRC commands double as natural language announcements for those that
are following activity on the IRC channel. Hashtags can be used to
attract other teams attention. You can announce later discussions, but
the commitment on exact timing is limited. Every "now" command would
clear "next" entries, so that there wouldn't be any stale entries and
the command interface would be kept dead simple (at the cost of a bit of
repetition).

I have POC code for this bot already. Before I publish it (and start
work to make infra support it), I just wanted to see if this is the
right direction and if I should continue to work on it :) I feel like
it's an incremental improvement that preserves the flexibility and
self-scheduling while addressing the main visibility concern. If you
have better ideas, please let me know !

-- 
Thierry Carrez (ttx)