OrganisingOnlineEvents

From The Art Of Community by O'Reilly (http://www.artofcommunityonline.org) by Jono Bacon

In recent years the growth of the Internet has produced an increasingly interactive Web. Gone are the days of an Internet largely populated by static web pages. Today the Internet is the same thriving and growing library it ever was; it’s just that now it is a library in which you can talk to the other visitors.

When we look back at the history of communities in which people worked together on the Internet, virtually all communication was handled in two environments: email or Usenet (groups in which you send email). Both of these media have always been slow. When you discuss a topic over email, it is entirely expected that a conversation can last days or even weeks, with hours in between each message.

Although email still dominates the world as a primary medium for general communication online, advances in real-time discussion facilities have made it possible to hold real-time meetings in which people converse together in the same time slot. This has raised the opportunity for online meetings in which multiple people can join and have a conversation.

Online events are something that I have used extensively throughout my work with Ubuntu, but it surprises me how little other communities have made use of them. In the Ubuntu community, they have been hugely useful and always netted upwards of 300 attending each event.

If you have a geographically dispersed community, here are some of the types of online events that could be useful to run:

Tutorial weeks:

These are special weeks in which a series of teaching and best-practice sessions are run to educate your community in how to do things. This has been used extensively in the Ubuntu community.

Release parties:

Many communities have online release parties to celebrate the release of a new piece of software, initiative, or some other project. Instead of meeting in a bar or restaurant, these parties happen online in a chat room, and people sit at their computers and have a few drinks while having a good time with each other.

Focused activity days:

These days are intended to bring the community together around a specific initiative. In the Ubuntu community, these events come in the form of Bug Days (designed to focus people on fixing bugs) and Docs Days (designed to focus people on improving the community documentation).

I have not included team meetings in this, as they are less special events and more an expected component in teams and governance bodies. Online events related to governance and conflict resolution were discussed earlier in the chapters devoted to those topics.

Common Attributes

Earlier, when we explored some of the organizational characteristics behind physical events, we discussed some common elements that apply to all events. This included accommodation, date/time, equipment, etc. We are now going to do the same for online events. The following are the common considerations that apply to all online events.

Medium

The first and most important consideration is what medium you want to use to host the event. Each medium that you use will need to be in real time: it is the instant gratification of real-time communication that makes events feel like events.

These are some of the attributes that you should look for in a medium:

Appropriateness:

Will the medium meet your needs? As an example, if you are running a training course for a few hundred people, a voice teleconference is inappropriate because only one person can talk at a time. However, you might deliver a talk and answer questions over a voice connection while accepting questions and allowing chat on a text medium.

Accessibility:

You should ensure that all of your community members can access the medium you choose. This depends a lot on your community. With this consideration, you need to determine not only whether your community has the technical facilities (e.g., computing power and Internet bandwidth) but also whether members are familiar with or able to learn how to access the medium.

Values:

You should ensure that the chosen medium meets the values of your community. As an example, if you are part of an open source community that values software freedom, you should not choose a medium that is closed source. Whatever your choice of medium, you should ensure that access to it is well documented and that your community is fully aware of where to find the documentation and how to connect.

Internet Relay Chat (IRC). Examples include:

Internet Relay Chat is a simple and efficient medium that is popular in the technical community. IRC is also open and transparent, and there are free clients for all operating systems. Another benefit of IRC is that it can host literally hundreds of participants at the same time, yet is low-bandwidth: it does not require a fast Internet connection. This is important if your community members may be using dial-up Internet access.

IRC has two downsides. First, it is text only, and some may not find it quite so engaging. Second, it is largely unknown in nontechnical communities. As such, if you decide on IRC for a nontechnical event, you will have to tutor your community on how to use it.

I have found IRC to be an excellent medium for organizing events. I have used it for many Ubuntu-related events, such as the Ubuntu Open Week, Ubuntu Developer Week, LoCo Documentation Days, release parties, and more. While IRC is useful, I have always been conscious to remember that most members start out unfamiliar with IRC and how to use it.

You should always ensure there are nice, clear instructions (with screenshots) showing how to connect with IRC.

Voice over IP (VoIP). Examples include:

Online telephony such as Skype or a Session Initiation Protocol (SIP) client such as Ekiga is the equivalent of having a conference call. As such, the same benefits and limitations apply: you can’t practically have more than 5–10 people in a conversation, but it does feel engaging. A downside of this medium is that it requires (a) a reasonably powerful Internet connection, and (b) sound hardware and a microphone, which may not be as common as you would expect. I have found VoIP to be useful for meetings, but not for general-purpose events due to the scaling issues. Another blocker for VoIP is that while Skype works great for many people, other clients require a significant amount of fiddling with firewalls and other networking mumbo-jumbo to get them working. When you organize an event, the last thing you want is your attendees fighting with the tools they need to connect.

Virtual worlds. One example is:

These 3D environments offer an interesting possibility for events. The largest and most popular is Second Life, which has literally thousands of people online. Virtual worlds offer an interesting physicality to an event. Second Life, for example, has hosted many events inside its environment, including gatherings, concerns, book readings, presentations, and more. In a virtual world, you have a physical avatar that you can move around in the world. While there, you can text or voice chat with other in-world avatars, buy and sell items, and create buildings and other things.

A particularly interesting feature with the voice chat in Second Life is spatial sound, in which the location of the sound in the stereo field changes based upon where the person is. As an example, if you sit between two people in a discussion, the person on the left will come out of the left speaker more.

Virtual worlds do, however, require significant computing resources to use (high-powered graphics card and audio hardware, significant Internet bandwidth) and also a good knowledge of how to use the world, navigate, and communicate with people. Although clients such as Second Life seem like an exciting bridge between the real and the online world, you should ensure they don’t block accessibility for your community. If the majority of your community can use Second Life, great, but if many struggle to meet the requirements, choose a different medium.

Date/time

When choosing an event date and time, be conscious that you are potentially open to a worldwide audience. As such, you are faced with the complex task of picking a time that will suit most of your likely attendees.

Here you need to take a reasonable survey of where most of your attendees live in the world and what times are going to be suitable for the majority. You are never going to make everyone happy all the time, and some people will complain because they won’t be able to attend. A common approach I have used is to pick a time that is in the afternoon in Europe. As an example, with Ubuntu Open Week (a week of tutorial sessions), I ensure that each day there are only four or five hours of available sessions but that they are spread throughout the week during European afternoon hours. This ensures that the West Coast of the U.S. can get online early in the morning, while on the East Coast of the U.S. is midday, and in Asia and beyond it is later at night. This approach has helped our events to hit the most people within the worldwide spread of contributors that are involved in the Ubuntu community.

Another complexity in picking times is communicating the time. There are many ways of describing different times, such as Pacific Time, Central Time, Eastern Time, Greenwich Mean Time, and Central European time. Daylight saving variations make it even more complicated. Fortunately, there is a solution to this in the form of Coordinated Universal Time and its ludicrously jumbled acronym, UTC.

When everyone uses UTC, people can calculate their local time zone offset based upon the difference between UTC and their local zone. Although many people are still unaware of what UTC is, I highly recommend you use it: it is becoming a more common reference as more communities have online events. When using UTC, it is recommended you still add other time zones next to the statement, e.g., “our next meeting will take place at 9 p.m. UTC (10 p.m. London, 2 p.m. San Francisco, 5 p.m. New York)”.

NOTE:

I highly recommend sending out a reminder two hours before the event via email, your website, Twitter, identi.ca, etc., to remind people that the meeting is happening soon. This will help remind people of the time and reduce time zone confusion.

Online Discussion Meetings

Communication within your community should always be your top priority. When the communication channels are open and conversation flows freely, your community gains momentum, progress is made, and your members will feel engaged.

Internal communication should seek to satisfy a range of needs that are involved in running a successful community. These needs are oriented around communicating progress on your goals, identifying direction, regular social connections, and day-to-day discussion. Meetings are a key component in ensuring your community is running effectively.

They provide a number of opportunities:

Discuss progress:

With your strategic plan and road map in place, you can use meetings as an opportunity to communicate progress on Objectives, Goals, and Actions.

Discuss solutions:

Meetings are a chance to discuss the implementation of solutions and any problems that your community may have.

Assign tasks:

Meetings are useful for identifying what needs to be done and getting people to volunteer to work on specific tasks.

Resolve conflict:

Every community has conflict, and yours will be no different. Meetings are a useful place to air issues and resolve personal conflict.

Within every community, a primary medium for regular communication should exist. Every community member should know they can come together with other members at an agreed place and at a regular interval to discuss and debate the issues that are before the community. This is the function of a regular meeting. The first step in getting regular meetings up and running is to choose a location. There are various options available, such as IRC, conference calls, and more. Personally I would recommend IRC, as these meetings will be open and relatively easy to access, and the conversations can be logged. You should ensure that wherever you choose to hold your meeting, the meeting is open to all and the tools required to join the meeting are freely available.

Choosing a time:

The next step is choosing a regularity and a time. Regularity is how many times you want the meeting to occur. This could be weekly, biweekly, monthly, or otherwise. Whatever you decide, choose that regularity and stick to it. Ensure that your regularity is bound to a day. As an example, your meeting could be “the first Monday of the month.” Regularity is largely dependent on your community and how much discussion needs to occur. I would recommend a minimum of one meeting a month and to increase the regularity if required. Choosing a time is a complex task for international online communities. You should look at your primary set of contributors and where they are based, and ensure you have your core contributors at meetings. Try to pick times that average out as suitable for the majority of contributors. This may involve some early mornings or late nights for some people to attend.

If you have a truly global spread of contributors, you may also want to alternate meeting times so that the early mornings and late nights don’t bite the same contributors every time. Some contributors will simply never be able to make the meetings due to the times. You should ensure these people can access meeting notes or a log of the discussion.

Advertising the meeting:

With these details in place, you should advertise it clearly to your community. The most common place to do this is on a website. Make sure you have all the details clearly available. You should also specify the time zone of the meeting. A useful tip here is to use the UTC time zone, which is internationally recognized.

Here is an example of how you can make your meeting available:

MyProject Monthly Meeting The MyProject Monthly Meeting is an opportunity for our community to come together to discuss progress, technical issues, problems, and other issues relevant to MyProject. Everyone is welcome to attend. WHEN: First Monday of every month TIME: 20.00 UTC – 21.00 UTC WHERE: #myproject IRC channel on irc.freenode.net

With the meeting text ready, it is time to ensure your community knows that the meeting exists. You should publicize your meeting in the places where your existing community and prospective community are likely to find it. The first and most obvious place is your website. Ensure that your meeting is prominently located: it should not be buried away behind some obscure menu options. You should have a link to the meeting on the front page of your website, and it should be common knowledge where to find the page.

You should ensure that the URL to the meeting page does not change. This is particularly important if the meeting time and date is changing and if you are using the page as a place to put the agenda.

You also should announce and publicize the meeting in your community’s primary communication channels. This could include your mailing list, in the topic of your IRC channel, and on blogs. The whole point of the meeting is to get your community together, so you should make every effort to ensure the community knows about it.

When the meeting is complete, you should also publicize the results. Many of your members will be keen to see what was discussed and what the outcomes were. Publicizing meeting results also indicates to your members that important things take place there. This will help them decide whether they want to join the next meeting.

NOTE:

With guerrilla marketing, not only are you marketing something, but you also encourage your community to market the same thing in their own way. An example of this is asking your community to do the marketing on their websites or in the signature of their emails. This is a useful technique for publicizing important community features and events such as meetings. You should encourage your community to share in getting the word out there.

Setting the agenda:

Every regular meeting should have an agenda set. This can be set by those who organize the meeting, but a preferred approach is to allow your community to submit agenda items. This ensures that everyone is welcome to use the meeting as an opportunity to raise issues. The method of soliciting agenda items is really up to you, but I would recommend that people add their items to an existing agenda so everyone can see the full agenda. This avoids duplication of agenda topics. A good method of doing this, and one used in the Ubuntu community, is to use a wiki. Put your meeting time and details on the wiki, and use the wiki page as a place for the community to add agenda items.

Running the meeting:

It is essential that your meeting is run well. There are few things more frustrating than a well-organized community meeting with an agenda that fails to reach any conclusions, fails to keep to time, and fails to cover all the topics in the agenda. Your goal is to keep the meeting moving along, ensure everyone gets their chance to speak, and ensure that outcomes are generated. The most important aim for any meeting is to generate output. At the end of your meeting, you want to ensure that there is something to show for it.

Now I want to share some best practices for chairing these kinds of meetings that will help you get the most out of your own meeting time:

Explain the structure:

Kick off the meeting and issue a general welcome. Make it clear at the beginning of the meeting that everyone is welcome to contribute to the discussion. Next, explain how the meeting works: a series of agenda items will be raised and discussed, and then action items will be generated for each topic.

Keep your eye on the clock:

Always keep a keen eye on the clock. If the meeting has a fixed length (usually an hour), keep to that time. This will mean determining how much time each agenda item has for discussion. This may also mean stopping the discussion on an agenda item to move onto the next topic.

Ensure speaking equality:

Some people in your meeting will dominate the discussion, and some will be more reluctant to chip in. To ensure that everyone gets a say, you may need to prompt the quieter people and ask if they have any comments. Naturally you should do this only if they are likely to have a comment: don’t just pick on people because they haven’t said much.

Focus on outcomes:

Always do your best to keep the discussion focused on finding outcomes and actions for moving forward. Every meeting has the potential to turn into a long discussion with no outcome or next steps. Always keep your mind focused on what needs to happen next to move the topic or goal along to the next stage.

There are pages and pages of content written in books about how to chair meetings well. Doing it effectively is very much a learning process, and it will take time for you to find your feet. I highly recommend sitting in on other, longer-established community meetings to learn how those chairs keep their meetings ticking along.

Organizing Online Tutorials

When I first joined Canonical as the Ubuntu Community Manager, I set myself a career-long goal of trying to understand how to bridge the gap between a user and contributor. Fundamentally, there is no difference between a user and contributor. Both are big bags of flesh and bones, but some people manage to get up and running as a contributor and some don’t.

A key driver in my mind was education. While we had oodles of documentation, people really learn when they sit in the same room, sharing a computer and pointer, gesturing, and sharing knowledge. Although I could not get our entire community in the same room, I was keen to get as close to that educational nirvana as possible.

With this in mind, I developed the concept of the Ubuntu Open Week: a week of IRC tutorial sessions that teach attendees how to do something. The week includes sessions for a wide variety of hands-on topics such as how to file a bug, how to triage bugs, how to create patches, how to translate the messages displayed by applications, and more. Each session is delivered by a competent community member, and most of the sessions have included upwards of 250 attendees. I am going to use my experiences with the Ubuntu Open Week as a basis to explain how to run your own online tuition sessions.

Scheduling

To create the Ubuntu Open Week, we first decided on when it should occur and how many days it should last. Traditionally I have run the event from Monday to Saturday so that those who cannot attend mid-week can join for at least one day. Each day usually has between three and five sessions. With this schedule I knew how many session leaders I needed to find. It is up to you and your community to determine what kinds of sessions are scheduled. Announce the completed schedule primarily within your internal community communication channels, such as mailing lists, chat channels, and on your website. You may also want to consider doing some external publicity to encourage new contributors.

Preparing for a session

Before you kick off your tutorial sessions, it is recommended that you ask your session leaders to prepare for the session. Even though each session lasts only an hour, that can feel like an awful lot of typing in the thick of things. As such, it is recommended that your session leaders prepare a script for a reasonable chunk of the session, with each item of discussion on a separate line. This script could look a little like this:

hi everyone! welcome to my session about how to apply as an Ubuntu developer in this session we are going to discuss the process of how you prepare, document and apply for approval as an Ubuntu developer ...

Grammar fans may have noticed that the script lacks uppercase letters and punctuation. IRC as a medium tends to lack these attributes, and as such, looks more free-flowing and conversational. You want your session leaders to sound this way, and so it is recommended they deliberately keep the script in lowercase letters.

Running a session

The way we have typically run the sessions in the Ubuntu Open Week is to have two IRC channels open at any one time:

#ubuntu-classroom:

This is the channel where the session leader delivers the tutorial content. It is expected that attendees do not speak in this channel while the session is in progress. If you do get excessive chatter, you may need to ask a channel administrator to mute the attendees.

#ubuntu-classroom-chat:

This channel is where people can discuss the session while it progresses and ask questions.Questions are an important part of a tuition session, but questions could easily get lost in the flurry of discussion in the #ubuntu-classroom-chat channel. So we defined and published a convention for people to ask questions. The attendee simply prefixes a question with “QUESTION.” As an example:

QUESTION: How do you attach a patch to the sponsorship queue?

This convention makes it simple for questions to leap out within the mass of discussion in the channel.

NOTE:

One of the excellent attributes that makes IRC so suitable for tutorial sessions is that the session can be logged easily. You should ensure every session is logged and put somewhere on your website for people to access.

Session logs are a great source of content. Many of the questions that are featured in the sessions could be source material for an FAQ, or the full tuition session log could be expanded into a full HOWTO document. These are excellent tasks that some members in your community might be interested in performing.

Event-specific notes

Medium:

IRC is the recommended medium for this type of event. IRC allows many people to join, is ideal for concurrently running a session and also allowing people to discuss it, and allows the session to be logged.

Date/time:

There are no additional considerations beyond the general notes that were discussed earlier.


CategoryBuildingCommunity

BuildingCommunity/OrganisingOnlineEvents (last edited 2010-08-06 21:23:24 by gw-sherb)