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) __________________________________________________________________________ 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