Marketing/Developer/Meetups HOWTO

From MozillaWiki
Jump to: navigation, search

How to organize developer meetups

This document is a guide for Mozilla volunteers who want to host developer-oriented meetups that are related to, or aligned with, Mozilla concerns. Contexts in which developer-oriented meetups might take place include:

  • Community Spaces that are not associated with a MozSpace.
  • MozSpaces that have physical space available for events; please note that events in MozSpaces must have an employee sponsor and follow additional guidelines.
  • Mozilla communities that do not have a Mozilla physical presence.

What is a meetup?

The term "meetup" was popularized by the website Meetup.com. It refers to an informal gathering of people who share a particular interest, typically on a regular interval. In the context of developer-oriented meetups, the key factors are "shared interest" and "regular interval". The shared interest should be broad enough to admit a wide range of topics, but not so broad as to lose cohesion. The interval should be frequent enough that members remember it, but not so frequent that organizers burn out. (More on this below.)

Types of meetups

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

Starting a developer meetup program

If you think you want to start a program of developer meetups in your community space, there are a few things to think about:

  • Which meetups will you host or sponsor?
  • Who will lead the meetups you host?
  • What are the criteria for holding a meetup in your space?
  • How often will you host meetups?

Deciding on meetups to host or sponsor

The most important step in deciding what meetups to host or sponsor is to find a match between the the needs of your local technical community and the technical interests of potential meetup leaders.

  • 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 what developers in your area want from meetups that they're not getting. (Caution: If you ask people what they want, the answer is often "we want everything". In that case, start with the knowledge and interests of your core organizing group to decide what to focus on.)

If there are 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.

Leadership team

A specific meetup group can be led by a single person, or by a group, depending on the situation, and the interests of the people involved.

There are a couple of necessary roles for developer meetups, described in the following sections. You can create additional roles by dividing responsibilities. For example, the responsibilities of the meetup host role could be divided so that one person takes care of promotion, while another handles the on-site details.

A best practice for meetup groups is to set an explicit goal of recruiting members to become part of the leadership team. Turnover of leaders is a natural part of the life of a group, so plan to replenish the team.

Meetup host

The meetup host is responsible for the logistics of the event: planning, promotion, refreshments, sign-ins, etc.

If you are hosting an external group in your space, you still need someone to be responsible for opening and closing the space, and making sure that the group can find what it needs.

Technical leader

It's very important for each meetup to have technical leader who is familiar with the relevant technology. This person plans the technical content of each meeting. They do not have to present the content every time; they can seek out presenters, from the group's regular attendees or elsewhere, to present on various topics. They also should be able to answer technical questions from meetup attendees, or know where to look to find answers.

This role is not purely technical. It is also about people: encouraging attendees to feel comfortable asking questions and to want to keep coming back.

If there is no technical expert in a subject available, but there is someone who is interested in learning about the subject, consider calling the meetup a "study group" (such as "Rust study group"). This makes clear to attendees that everyone is on the same level of knowledge, and therefore the group will work together to find answers to questions.

Criteria for all meetups

Each community space has "house rules" that individuals and groups using the space must abide by. In addition, to put into practice Mozilla's participation principles, be sure that all meetups have a "Code of Conduct", to ensure a safe and respectful environment for all participants. Groups do not have to use exactly the same code of conduct; some groups that are part of a larger movement (for example, PyLadies) might have a code of conduct from the broader organization. But all groups should have one, and leaders should be prepared to enforce it. See Code of Conduct 101 + FAQ for more information about why codes of conduct are important, and where to find examples or templates.

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.

As an example (your specific meetups might be different), you could start with a schedule like this:

  • Week 1: Web Developers
  • Week 3: Firefox Engineering contributors

Once those meetups are well-established, you could add more:

  • Week 1: Web Developers
  • Week 2: MDN Localization
  • Week 3: Firefox Engineering contributors
  • Week 4: Firefox DevTools users

When creating a developer meetup program for a community space, try to find at least one organizer or host for each meetup type. If one person tries to organize multiple meetup types, they may become overworked and burn out of the role. It is better (and hopefully more fun) to share the load by spreading the organizing across multiple people. It is perfectly OK to have 2-3 co-organizers for a meetup type.

Processes

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

Booking the space

See the website for your local community space, or talk to a "keyholder" for the space. See the Community space initiative page for links to the community space websites. These sites also can tell you the capacity and facilities of the space (number of people, wifi, etc.).

Budgeting and approval

Budgets for Mozilla-supported developer meetups go through the Mozilla Reps budget approval process. If another department of Mozilla is funding the event, use the special case process; in such a case, the budget does not need to be approved by the Reps Council, but they provide feedback on the budget and a mechanism for reimbursing volunteers.

If you are organizing a meetup, and you are a volunteer who is not a Rep, find a Mozilla Rep who can submit the budget request. If you are using a Community Space, the "keyholders" of your community space are typically Reps, or can help you find a local Rep.

You can also seek third-party (that is, non-Mozilla) sponsors for a meetup. For example, a thriving developer meetup can be very attractive to tech firms in your area who are looking to recruit new employees. You could give them the opportunity to make a 5-minute pitch in exchange for sponsoring refreshments. Be careful, however, to avoid tying sponsorship to the main content of the meetup. If attendees feel that the meetup content is a sales pitch, or that their attention has been bought by a sponsor, they will quickly stop attending.

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.

Some sites that can help with event promotion and registration include:

These are not the only ones, and there may be others that are more popular in your locale.

Collecting data

Collecting information about attendees at your meetups is important for tracking the evolution of your groups, and for sharing your results with larger groups within Mozilla.

Contact information

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. If you have a problem of too many no-shows, try charging a small fee for registration, to encourage commitment. The proceeds can go towards refreshments, or even be returned to registrants who actually show up.

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)
  • newcomer vs. repeat attendee

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.

Aggregate stats

You don't need to share attendee contact information with anyone outside your group. However, for community space meetup programs, the Participation and Developer Marketing groups are interested in the following aggregate statistics:

  • For each type of meetup:
    • Number of attendees
    • Number (or percent) of newcomers
    • Number (or percent) of repeat visitors

It's not important to get as many attendees as possible. For example, a meetup that has 5 attendees might focus on growth, one that has 20 attendees is a comfortable size, and can focus on sustaining the group: keeping a steady flow of newcomers, as well as a steady base of repeat visitors.

Qualitative data

Every meeting of a meetup group is an opportunity to learn more about the attendees. Paying close attention to questions that they ask or things they say about themselves can give you clues to:

  • What is the level of technical skill within the group? Are there clumps at different levels (beginner vs. experienced)?
  • What types of topics are attendees interested in hearing more about?
  • Who has expertise or interesting experience that they could share with the group?

These insights can guide you toward the needs of attendees, and potential directions for future topics.

Conducting the meeting

Here are some suggestions for conducting a meetup, as a host:

  1. Introduce yourself as host
  2. Point out health and safety facts (fire exits, toilets, smoking rules, etc.)
  3. Go through the points of the Code of Conduct; this sets a clear expectation that if someone does not behave respectfully, they will be made to leave.
  4. Outline the agenda, that is, what will happen when.
  5. Introduce the speaker, topic, activity, etc. In other words, get on with the meeting.

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 receive.

Example Survey

  • This meetup was worth my time. (Select a number to rate.)
 Agree 4 3 2 1 Disagree
  • I would recommend future meetings of this meetup to my friends/colleagues. (Select a number to rate.)
 Agree 4 3 2 1 Disagree
  • What I liked best about this meetup was:
  • Something that could be improved is:
  • Other comments:

Content and format suggestions

The format of a meetup can range from a basic presentation plus Q&A to participatory learning or contribution sessions. A presentation is the easiest type to prepare, but a hands-on session is more engaging for attendees. You can also have a mixture of formats; for example, at a Firefox Dev Tools meetup, someone could present a Dev Tools feature, and then have time for attendees to play with the tool hands-on. (In such a case, provide a sample project to work with, so attendees don't have to start from nothing.)

If attendees need to bring a laptop or install software in advance, mention this when you promote the meetup, and if you send a sign-up confirmation. If you are providing loaner hardware (laptops, phones, maker kits), collect something of value in exchange for the item (such as an ID or a small fee), to be returned when the hardware is returned.

For sessions involving Mozilla contribution (coding, QA, localization, etc.), be sure to have experienced contributors on hand to mentor newcomers. If you use a sign-up form, you could ask for attendees' experience level; you can tailor the introduction based on these responses. You might want to set up tables with at least one mentor at each one. You can also use IRC or another IM platform to ensure that others benefit from seeing answers to questions.

See also

  • Building BrooklynJS: How the BrooklynJS meetup grew from nothing to become one of the most vibrant JavaScript meetups in the world.
  • A UX designer's presentation on Designing Better Meetups; valuable not necessarily for the specific advice, but for the approach to the issue.
Retrieved from "https://wiki.mozilla.org/index.php?title=Marketing/Developer/Meetups_HOWTO&oldid=1134992"