On 18 May 2017, at 2:57, Thierry Carrez wrote:
> 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 Seems like a reasonable idea and helpful tool. For the Swift team, we generally end up with more than one thing being discussed at a time at different tables/corners in the same room. A "#swift now discussing foo, bar, and baz" (instead of one-thing-at-a-time) would be how we'd likely use it. I'd guess other teams work in a similar way, too. --John
signature.asc
Description: OpenPGP digital 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