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


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

Reply via email to