I agree with pretty much everything John's written, especially with regards to what's required of a host (and accepting that things will have to be different at the PTG).
For security, although we have a pre-event etherpad to propose topics nothing is decided until the first day, where we will have an unconference, vote on things we want to talk about and try to create a schedule that doesn't clash. We have on a number of occasions conducted our mid-cycle overlapping with Barbican, where we've been able to participate in each other's projects, vote on topics, register interest etc. This cross-polination has been very useful and works well in an unconference setting. -Rob On Wed, Oct 12, 2016 at 6:30 PM, John Dickinson <m...@not.mn> wrote: > The Swift team has been doing midcycles for a while now, and as the new > PTG gets closer, I want to write down our experience with what has worked > for us. I hope it is beneficial to other teams, too. > Logistics of the event > > - 2 rooms is ideal, but can make due with one larger room > - move tables and chairs > - whiteboards/flip charts > - projector/tv > - host provides lunch and snacks > - host provides one evening meal/event > > When someone offers to host a midcycle, this is what I ask them to > provide. The PTG will be slightly different, but the general idea is the > same. There's a few important things to note here. First, be flexible about > who's talking about what and when people are working together. The point of > getting together in person is to facilitate face-to-face communication, so > be sure that the room logistics don't get in the way by forcing people into > a certain configuration. Providing lunch and snacks allows the participants > to not break any tech or social flow in the middle of the day. It keeps > people together and helps facilitate communication. And the one evening > event is super helpful to let people relax, have fun, and do something > interesting away from a computer. In the past we've done everything from > locked-room challenges and bowling to brewery tours and a boat ride under > the Golden Gate bridge. > Only agenda item is "set the agenda" > > - dotmocracy > - too much to do for the people we have to work on it > - what's the big stuff we need the right people to be together for? > - schedule one big talk each am and pm > > When it comes to the actual flow of the limited time together, there are > two important things to keep in mind. First, make sure there's time to > cover all the topics that are of interest to the people in the room. > Second, make sure the big important stuff gets discussed without requiring > someone to be in two places at once. > > Unfortunately, these two goals are often in conflict. We've solved this in > the past by starting the midcycle with one and only one agenda item: set > the agenda. The most successful way we've done this is to ask the room to > shout out topics to discuss. Every topic gets written down on a piece of > paper or on a flipboard. When you've got all the topics written down, then > give everyone a limited number of dot stickers and ask them to vote for > what they want to talk about by placing one or more dots next to it. The > trick is that there are more topics to talk about than people who are there > and each person has less dots than the full schedule of time we have. So, > for example, if there are 3 days together, that's a total of 6 morning and > afternoon blocks of time. Give everyone 4 dots, and force them to > prioritize. This also has the very real visual side effect of emphasizing > that we are a team and not one person can be a part of everything going on. > After everyone has put their dots on topics, sort the topics by number of > dots. In our example, we've got 6 blocks of time, so choose the top six and > schedule them. This ensures that the big stuff can get scheduled, the > little stuff can fill in the gaps, and people can know when to be available > for conversations that are important to them. > > Imagine than you've got a glass mason jar, and you need to fill it up with > stuff. You've got big rocks, small rocks, sand, and water. If you fill it > up with water first, the water will spill out when you add anything else. > But if you add the big things first, then you can fit more in. The big > rocks go first, then small rocks fill up the spaces, then sand fills up the > cracks, then the water can seem in the tiny air gaps. It's the same way > with prioritizing the in-person meetings. Schedule the big stuff, then fill > in any gaps with the small stuff. > Social dynamics during the week > > - you won't be able to participate in everything. that's ok > - there will be several conversations going on at one time. be > considerate and flexible > - don't wait for someone to start a conversation. start it yourself. > this is very important! > > There's a lot going on at in-person meetings. It's ok to not participate > in everything--you won't be able to, so don't even try. In the best case, > there will be a lot of conversations going on at once, so be considerate > and flexible. It's important to not sit back and wait to start a > conversation--if you need to talk about something, grab the right people, a > whiteboard, and a corner of the room and start talking. > > But what do you talk about? Sometimes it's just talking with a whiteboard. > Sometimes it's reviewing code together. And occasionally, there's even an > opportunity for some pair programming. > > After a topic has been talked about, check it off on the big list of > topics that you made the first day. This keeps everyone aware of what has > been talked about and what needs to be talked about. And by the end of your > time together, it's a great visual reminder of the success of the week. > Have fun > > Overall, have fun. In-person meetups are a too-rare opportunity to meet > with interesting and diverse people from around the world. The Swift > midcycle hackathons we've had in the past are some of the most enjoyable > events I've ever attended, filled with some of the smartest and most > interesting people I've worked with. I hope your time at midcycles and the > upcoming PTG is as productive as our team's meetings have been in the past. > > --John > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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