OpenStack midcycles are self-organized events where development teams gather in tight knit groups and hold face-to-face discussions. As opposed to the larger design summit events, there are typically no new features or design directions pitched at midcycle events. Instead, we utilize the opportunity to hammer out the final details on problems large and small. And of course, it's always a great opportunity for team building.
Despite the keystone community holding six midcycle events at five venues in four cities, we've never held a formal retrospective to discover what works for us and what doesn't — until now. As our last group activity of the Newton midcycle in San Jose, California, we compiled a huge amount of feedback that I'm going to attempt to distill into something useful here.
Whether you are organizing or attending your own project's midcycle event, I hope you'll find these ideas to be useful data points in your planning process.
Etherpad: A single Etherpad is a core component of every midcycle event. Create one well before the event, and use it as a single source of truth for everything from the first draft of the agenda to final outcomes.
Large group discussions: These are the topics which not only impact the entire group, but would also benefit from the expertise of the group as a whole. Plan major topics well in advance to give everyone time to prepare. To avoid fatigue and maximize productivity, there should only be a very small number of major discussion topics, and they should be spread over the first two days of the midcycle. These topics should have highly polished specs either approved or in code review. Each major topic should have:
A well-defined problem statement, along with any known design constraints. Large "bucket" topics such as "federation" do not efficiently lead to productive outcomes. Constraining large group discussions to topics with corresponding specs makes this easy.
A self-selected champion to introduce and lead the discussion. Usually, this is the person who proposes the topic for discussion.
A dedicated moderator who is impartial on the topic but knowledgeable of it nonetheless. The PTL should generally be a good default choice. The moderator is also responsible for stopping or removing sideline conversations which are distracting to participants.
A dedicated scribe to capture potential solutions and outcomes. Although it is still everyone's job to take notes collaboratively, it is ultimately the scribe's responsibility to ensure that outcomes are properly captured.
Small group breakouts (unconferencing): About half the midcycle should be dedicated to breaking out into small groups where highly-focused topics can be discussed, designs can be hashed out on white boards, and code reviews can happen collaboratively. The difficult part is in organizing the chaos, communicating with all attendees what topics are being discussed where and when. Consider using a whiteboard or sticky notes to propose and organize topics on the spot, and self-organizing from there using either a birds of a feather or a dotmocracy approach. Most importantly, be conscientious to document rationales and report back to the group as a whole with outcomes and action items.
Presentations: Midcycles are unfortunately not an appropriate venue for most presentations. Even for demos intended to spark discussion, record the presentation and share it with attendees ahead of time. If it can't be summarized and linked in an Etherpad, then it does not have a place.
Remote participation (video conferencing, etc): This doesn't work too well, particularly for large group discussions, unless the entire midcycle is conducted remotely. Because of all the limitations imposed by microphones, cameras, displays, latency, etc, participation tends to becomes a lop-sided, one-way affair which can become frustrating for those on both sides of the connection.
Newbies: Midcycles are a great way for newbies to participate face-to-face for relatively minimal cost (no $1,200 tickets or active technical contributor status required). Be accommodating to them by letting them know what to expect, communicating openly, make time for questions, and make personal introductions at the beginning. As a related protip, if you have a question during a discussion and feel it would be an interruption to ask, try posing the question in the Etherpad or in the group's IRC channel. Odds are, someone else is lurking and would be happy to answer or provide context. Volunteering to act as a scribe during large group discussions is great ways for newbies to rapidly become very actively involved with a well-defined role.
Action items: Midcycles often result in a list of agreeable action items, but those must have specific assignees to be useful. Action items should be clearly written for anyone to comprehend and act on — not just the scribe or the intended assignee. One of the action items should be to send a reminder email after the midcycle with a summary of outstanding action items and assignees.
Summaries: Not everyone can attend every midcycle, attendees cannot be involved in every discussion, and those who were not in attendance will have a difficult time following the proceedings from the Etherpad alone. If you're inclined, take the opportunity to summarize the discussions and outcomes, and publish them to a blog or mailing list.
Seating layout: Midcycles require collaborating both as a large group, and in smaller groups. No space is perfect, but a conference room style layout is great for large group discussions, and space for people to move chairs around freely is great for breakout discussions.
Scheduling: The daily proceedings of a midcycle should be scheduled in broad strokes. That is, choose a fixed start time, end time, and allocate sufficient time for breaks (at least 10 minutes), and appoint someone to keep the group on schedule. Midcycles are mentally taxing, and brain cells need frequent opportunities for rest, calories, and caffeine.
Capacity: The number of attendees at most midcycles will tend to be limited by the capacity of the venue itself. It's possible to have too many cooks, or too many spectators, in the kitchen, which ultimately limits productivity and the success of the event. While there's no ideal number of attendees that would work for every community, organizers should think small, but not exclusive.
White boards: Multiple whiteboards or drawing pads allow small groups to function in parallel, and are fundamentally required.
Large format display (such as a projector): A shared display is handy for displaying the Etherpad, collaborative code reviews, and spec discussions.
Breakfast & lunch: Healthy options are appreciated. Caffeine is a must. Catered meals are fantastic, but they're ultimately optional if the venue has immediately available food options that can satisfy a large, diverse group (such as a sandwich shop or food trucks). Taking a big group out to lunch is not time efficient. The venue organizer should at least have a plan for food options for each day, and communicate them in advance.
Dinner: Communicate a dinner plan for the whole group well in advance. Include the date, time, venue, and where necessary and possible, take RSVP's and make reservations with the restaurant. Everyone loves a sponsored dinner, but that's not strictly necessary. Do try to accommodate a variety of diet restrictions, keep costs down, and limit the need for special travel arrangements.
Team building: Plan a social extra curricular activity that with a low barrier to entry (low cost, no specialized skills or athleticism required to have fun), and either include it as part of the day's schedule, or integrate it as an evening activity. Board games in the hotel lobby or a trip to the bowling alley.