Jens Harbott wrote: > With the current PTG just finished and seeing discussions happen about > the format of the next[0], it seems that the advantages of these seem > to be pretty clear to most, so let me use the occasion to remind > everyone of the disadvantages. <…> > So when you are considering whether it is worth the money and effort > to organise PTGs or similar events, I'd like you also to consider > those being excluded by such activities. It is not without a reason > that IRC and emails have been settled upon as preferred means of > communication. I'm not saying that physical meetings should be dropped > altogether, but maybe more effort can be placed into providing means > of remote participation, which might at least reduce some effects.
I have been involved in many physical gatherings in many communities over a number of years, and have concluded that there is no substitute for occasionally being able to look over someone else’s screen (or have them look over yours), bumping into folk after sessions in the hotel and ending up hunting down someone else for a discussion you forgot, or even just having lots of folk in the same timezone. Broadly speaking, I believe that the total velocity of a community is enhanced by 10-20% by having physical meetings. Experience with groups that meet monthly, semi-monthly, quarterly, semiannually, and annually suggests that the most effective balance between the benefits of meeting and the penalties of travel is quarterly, ideally with a larger group about half the time and a smaller group the other half of the time (echoes of Thierry’s comments about inward vs. outward in another thread). That this happens to be a close match to OpenStack is either a coincidence or that others in our community share some of my experience. Sadly, there are no good solutions to extend the benefits of such meetings to folk that don’t make them, but over the years many communities have adopted various practices that significantly reduce the productivity losses of non-attendees during the events. These are not substitutes for attendance (even if only occasional attendance), but they do a lot to reduce the amount of guesswork that non-attendees must perform afterwards. Using Etherpads If there is a discussion at a physical meeting that involves more than a couple people in the hall, an etherpad (or similar shared documentation solution) should be used to take notes. This both ensures that participants correctly remember the discussion (as with so much happening during a week, things easily slip out of focus), and makes the content discoverable for non-attendees, if only to inform future reviews or mailing list posts. Ideally, there is a fairly simple way to make these documents discoverable, such as having the URLs posted to channels on a per-topic basis, or similar. Video streaming and recordings of presentations Where there are formal presentations (e.g. the lunch presentations at the recent PTG), streaming them ensures that non-attendees are able to follow along and have context. Ensuring they are recorded and promptly posted helps those in different timezones follow along. Having them archived can significantly reduce the effort involved in catching up to speed for new community participants, as they can review what was presented at the conference they didn’t know they wanted to attend remotely, as well as building face-to-name mappings that will serve them well if they are a future attendee. Public internet audio streams Streaming audio from meeting rooms and selected lounge spaces is incredibly useful for larger discussions, especially those conducted fishbowl-style, with a few primary participants and others hacking in the corners. When one knows a meeting Is scheduled, and can follow the discussion and etherpad, one can be a very effective participant, even remotely (assuming compatible timezones or personal timezone shifts). Streaming from lounges allows non-attendees to also participate in ad-hoc “hallway” discussions sometimes, albeit to a limited degree. This can be very useful when something runs over a time box, but a few participants wish to continue chatting for another 10 minutes. Unfortunately, this requires rather a lot of infrastructure and can be fairly expensive. Audio conferencing I have participated in conferences where each room is wired to a two-way bridge, rather than just streaming, both as an in-room participant and an external participant. I have been unsatisfied with the experience in both directions. Some problems include incorrect volumes on the PA, remote folk speaking over each other (or with unexpected lag), limitations of classic telephony codecs when dealing with many people speaking simultaneously in a room (partly mono vs. stereo issues, partly distance-from-mic issues). I have had success with arranging specific remote contributors to connect to separate devices for specific sessions. This usually happens by appointment, with one of the physical participants using some device to connect to the participant. I once participated in a meeting with two such remote participants, and it worked much less well, largely due to the audio lag in each session meaning the remote participants could not converse with each other (making both feel more remote). IRC Projectors: Having dedicated per-room IRC channels with projectors on the wall can work fairly well, as folk in-room who are not looking at their laptops will notice comments on IRC. I have observed fairly long conversations where some participants are speaking and others typing, for good inclusivity of all involved. These are ideally not the regular channels used for project communication, as this mechanism does not work as well for channels that are high-volume or are used for topics other than that being discussed in the room. Nothing Happens policy: Establishing a policy that no decisions can be taken during physical meetings is hugely valuable to ensuring that everyone has a voice: if people think they have consensus, they submit the results of this to typical fora (e.g. mailing list, gerrit, etc.) for review, some of which review may happen in person, but only coincidentally. Making this work well depends on everyone expecting that process during all steps (including the content of the conversations causing posts and changes), to avoid anyone saying “but we decided at Summit”, which suddenly destroys the discussion. (Note: “Summit” was chosen as an event that doesn’t happen anymore, to avoid blaming any specific event) Wide geographic rotation Having regular meetings in widely different geographic locations tends to cause the population attending meetings to change over time. This both forces attendees to recognise that not everyone is present and increases the number of folk that sometimes to not attend, which helps drive policies that support those who cannot attend (either occasionally or ever). For example, one conference I used to attend that rotated between APAC, EMEA, and the Americas over each year tended to have about 50% all the same people, 35% people from the relevant continent and 15% random folk who happened to be able to travel that week. Continued regular team activities: Teams that halt everything for an event, and then start again after the event end up blocking all team work (sometimes for two or three weeks) during the hiatus. It may be that a subset of the team is productive at a meeting during that time, but ensuring that regular meetings continue to be scheduled, time is set aside to do reviews or respond to mail, etc. both helps the team gain higher productivity gains from the meeting (due to less losses from the hiatus) and ensures that non-attendees can continue to work normally despite the meeting. Regular Updates: Reporting on events ranges from proceedings documents that appear months afterwards to active microblogging of nearly every statement. I do not typically find either of these useful as a remote participant. My personal preference for this consists of a) IRC notification of the start of most larger discussions, and b) summary posts of topics at conclusion (could be as simple as “We talked about foo, we reached consensus, and bar will submit a change. The etherpad is at baz.”). Telling folk about lack of consensus is as important as reporting consensus: that helps remote participants who aren’t able to align their personal timezone appreciate where spending their day thinking about something can have value. External Conference tracking: Some communities in which I’ve been involved make a practice of tracking whether anyone will be at conferences hosted by others over the year. Where there are a few folk who are going, it often makes sense to try to schedule some time to meet up. While not a substitute for broad community meetings, this practice can help many folk who are commonly non-attendees to be able to occasionally meet with folk, and get some of the benefits of physical interaction, ideally somewhere much closer to home, and perhaps only for a day or a few hours, rather than a full 10-day international excursion. — Emmet HIKORY
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
