Marketing/Developer/Meetups HOWTO

Playbook for Developer Meetups at Community Spaces

DRAFT to be moved into Main namespace when more complete

This document is a guide for Mozilla volunteers who want to host developer-oriented meetups in Community Spaces that are not associated with a MozSpace. Much of this guidance also applies to developer meetups in MozSpaces or in communities that do not have a Mozilla physical presence. Please note that events in MozSpaces must have an employee sponsor and follow additional guidelines.

Deciding on meetups to host or sponsor

The most important step in deciding what meetups to host or sponsor is to evaluate the environment of your local technical community.

• Are there existing technical meetups? (Check meetup.com, or local equivalent.) Are these aligned with Mozilla interests? (e.g., JavaScript, Rust, web technology in general)
• What areas of content or interest are not covered by existing meetups?
• Consider conducting a survey to find out developers in your area want from meetups that they're not getting.

If there no existing meetups for developers in your area, you can start a meetup with a very broad scope, such as "web development". If there are many meetups already, it might not make sense to create another one, but rather invite some existing meetups that are aligned with Mozilla to meet at your space. If there are some existing meetups, try to fill gaps in the content that they cover.

Types of meetups

The following are suggested types of meetups you could host, but definitely not all possibilities.

• Mozilla-specific
  • Hands-on with Firefox DevTools
  • MDN Localization
  • Firefox engineering contributors

• More general technical
  • Web development
  • Hardware hacking (e.g., Arduino)

Frequency

How often should you hold meetups? Once a month is a good cadence for any specific type of meetup. One developer event per week in the community space is a minimum target to sustain activity and interest; two per week is preferable. Therefore, a good initial target is four monthly technical meetups, one each week.

Add more meetups or events depending on attendee demand. Don't try to do too much too soon. If there is attendee interest in a specific new type of meetup, try it as a one-off meeting (or a few meetings) before committing to a new regular meetup on an ongoing basis.

Processes

The basic processes for hosting a developer meetup are not different than for any other kind of event. You need to plan in advance; manage during the event; and follow up afterward. The [/ReMo/SOPs/Event_hosting|Mozilla Reps wiki] has general-purpose advice about running events. The advice below is specific to developer-oriented events.

Promoting the meetup

Promote your meetup in places where developers in your area will see it. Be sure to use any existing developer-oriented social media or discussion forums for your area. Stand up and make an announcement at other existing developer meetups.

Keeping track of attendees

You probably want to request people to sign up for the event if they plan to attend. This helps you to have an idea of how many people to expect (even though it's not exact, because some people attend who don't sign up, and vice versa). That way, you know how much refreshments to buy, and whether you might exceed the space capacity.

In addition, it's very important to also collect sign-in information from those who actually attend the event. You can use this information to promote future related events.

Be sure to record:

• name or nickname
• email address
• what event they attended (date and type)

Be sure to follow Mozilla best practices to protect personal information. If you collect sign-ins online (such as a Google form and spreadsheet), ensure that only people who need access to them have access to them. Be sparing in using the information (don't spam), and allow people to opt out later.

Solicit feedback

Asking for feedback is the best way to know how to improve. It's a very good idea to send a survey to attendees after every meetup. Keep the survey short, to maximize completion rates. Use the same questions every time, so you see trends over time. Read and consider all comments you recieve.

Example Survey

• This meetup was worth my time.

 Agree 4 3 2 1 Disagree

• I would recommend future meetings of this meetup to my friends/colleagues.

 Agree 4 3 2 1 Disagree

• What I liked best about this meetup was:
• Something that could be improved is:
• Other comments: