In this module you’ll learn about the different types of communication channels, or “comms” you can use to help your community discover, explore, and contribute to your project.
Suggest changes
Format
  • Read and watch videos
  • Writing and planning exercises to establish and document regular communication with your community
Prerequisites
  • A project with content like a README file and contribution guidelines
  • Online contact information (like email addresses or social media user names) for project participants
Materials

Access to your GitHub project repo

Intro to Communications (a.k.a. Comms)

“Comms” are the communications channels you use to help others discover, share, and contribute to your project. You want to send your comms out in the open; they should be easily findable and show people how to get involved with your community’s work.

Comms also give project members a chance to talk with one another and support each other’s contributions to the project. In the video below, see how Coral Project Community Lead Sydette Harry describes how the Tiny Letter tool curates and archives online conversations about ‘creating common ground’ for collaborators in open journalism projects. Sydette and her colleagues are working to create a web-based platform and shared space for journalism communities to discuss their shared values, interests, and work.

Why Do Comms Matter to an Open Project? Sydette Harry

Useful Communication Channels for Open Projects

For contributors, your GitHub repo is likely to be the central hub of communication about the project itself. When contributors interact with one another on GitHub (by mentioning one another in their messages using @username) and issue pull requests (PR), they receive notifications on GitHub and/or through email indicating that they’re needed in a conversation or to review new work.

Your contributors are the volunteers to who create content for your project - anything from code to codes of conduct, and everything in between. Contributors share the project’s workload with you and bring their time, talent, and generosity to attacking the problem your community and project want to solve.

Sometimes community members also link out from GitHub to other sharing docs like an Etherpad or Google Doc, commonly-used platforms for asynchronous planning and collaboration. They might also use chat channels like IRC, Gitter, and e-mail (mailing-lists, as an example). Keep in mind that one to one emails are okay but they should probably be replaced with more public communications in the name of openness around the project.

However, other participants and community members less directly involved with the day-to-day work of the project still want to know what you’re making, how they can contribute, how it will help them,and when it will be ready to access. You can use a variety of communication channels to keep your larger community of potential supporters and users informed about your project’s progress. Which channels and forms of communication you choose or create should be determined with accessibility and inclusivity in mind. Use the tools that are available most broadly in your project’s community. When you’re planning communication channels, think back to your Building Community module work and strive to create or find the channels that best fit your contributors’ and community’s needs.

At the very least, consider creating a shared calendar of events and two kinds of communication channels to help people find and keep up with your work. You may even decide to establish a third channel on a platform more familiar to you than your community. For example, if you don’t have a project page on Facebook, but your community uses Facebook all the time, you should show up there. Creating these channels is another area for co-creation and delegation: inviting contributors to work on comms is a great way to raise others’ voices in the project.

Your shared calendar can make it easy for community members to follow upcoming events and schedule their own project-related calls and convenings with minimal conflict. Use something like an Google Calendar to help your project members feel like they know what’s next. Sharing calendars lets you see your contributors’ availability and it lets them see yours. It’s easier to schedule meetings and send invitations community members can accept when you know one another’s schedules.

Next, create some kind of online presence that people can find through search or social media. This is kind of like the landing page for your project - the front page people should encounter first when they search for your project online.

If you or a volunteer contributor have some basic knowledge of HTML, consider building a web page for your project and hosting it from your repo with GitHub Pages. Online tutorials like this one guide like this can help you get started. You can, of course, host your webpage somewhere else depending on your needs and the web expertise in your project community.

If your community doesn’t have much web expertise, you can ask around to see what social media channel your community members use to communicate (such as Facebook or Twitter). You can create an account for your project on a social media platform that’s widely used by your community and reference that account in your documentation as the home base for your online presence. If you need help, look for an exemplar or mentor community to give you feedback and help, like the Mozilla Design Community.

After establishing your web presence, create a communications channel or publication that lets you regularly update your entire community on your project’s progress. While you can do this through social media updates via a project account, you might also develop more in-depth platform for sharing news like a community call (over the phone or video conferencing), newsletter, or development blog. Here’s a clip from a Mozilla community call on International Women’s Day.

Mozilla Community Call on International Women’s Day

Community calls are regularly scheduled phone calls or webcasts that any community member can listen to, watch, and otherwise participate in live. Generally each call follows an agenda shared ahead of time that includes times for call organizers and project contributors to share updates, as well as time for less involved participants to ask questions about what’s been going on in the project. The agenda is typically published as a shared document so call organizers and participants can take notes during the call. You can see an example of how Mozilla’s learning community structures its community calls here.

A newsletter is a form of communication you can draft and send on a regular basis. You can collect updates from core contributors and survey your project for particular needs to share via email with anyone subscribed to your newsletter. If you choose to use a newsletter to talks/share about your project, make sure you meet your commitment to publish it regularly.

Moreover, make sure that it’s easy for people who find your project to subscribe to the newsletter. Services like Mailchimp offer HTML email and newsletter design software free to small projects and communities.

As you set up your newsletter, be sure to protect any email addresses you collect by sending the email to recipients using bcc or by using a mailing list you create rather than including every subscriber’s email address in the “to” line of every mailing. While your project is an open one, you should safeguard as much personal information about your contributors as possible so that sharing their email addresses or anything else about themselves is a choice they make.

One other option for sharing updates is a development blog like this one from the Coral Project). A blog is a web page made up of posts that share news about a project. Platforms like Wordpress let you create a blog without knowing much HTML. You can compose and edit your posts using a text-editor instead. A development blog might be just the thing to serve as both an easily discoverable landing page for your site and a regularly updated comms channel for your community.

Assignment: Start a Shared Calendar

(10-15 minutes)

Using a service like Google Calendar, chart upcoming opportunities for project members to meet online or off. Also consider posting essential milestones for your project.

Assignment: Build a Web Presence for Your Project

(30+ minutes)

Survey your contributors and other community members to see what kind of web presence they think would work best as an easily discoverable landing page for the project. You might do this through a GitHub issue (e.g. “Let’s develop our web presence”) or use a simple online survey tool like Google Forms or Survey Monkey.

Work to reach consensus about what kind of web presence makes the most sense for your project. Then ask community members if any volunteers have the expertise necessary to build that site or create that account. Work with them to get your landing page or main social media account set up. Finally, add the address of your landing page to your project documentation and share it widely with your community and others who might benefit from its work.

Assignment: Create a Comms Channel for Your Project

(20-30 minutes)

In consultation with community members, determine a format for sharing updates about your project on a regular basis. You might set up an online community call, publish a newsletter, or commit to writing posts for a development blog alongside core contributors.

While you might have to create on these channels from time to time, your primary responsibility here is to make sure as many contributors’ voices are heard as possible by helping them to share their progress with others. Help your community figure out which channel works best, work with volunteers to set it up, and stick to your commitments to steward and publish updates on a regular basis.

next: Running Awesome Events  

Help us improve content and suggest changes to this page.