MDN/Hack on MDN/How to guide

How to run a "Hack-on-MDN" event

This page provides guidance on planning and running a "Hack-on-MDN" event. See MDN/Hack on MDN for background on these events.

Planning

Determine the goals

Have a clear idea of what the goals are for the event, for both content and community. This helps drive your planning of lower-level details.

• Do you want to document a particular topic area?
• Do you want to create a particular type of data, documents, or resources? For example, code examples or translations in a particular language.
• Do you want to attract new people to contribute to MDN?
• Do you want to increase cohesion among existing community members?

Pick dates and times

For in-person stand-alone events that require travel, we've found that three days (such as two weekend days plus one weekday) is enough time to get some significant work done, without taking too much time away from everyone's normal lives.

For events in conjunction with another, larger event such as a conference, a single day added on before or after the main conference works well. If the conference already has an "extra" day for tutorials or open-source "sprints", you may be able to piggyback on resources such as space that are already allocated. Work with the conference organizers as early as possible in this case, and ensure that your event is included in their promotions, so attendees know to include the extra day when booking travel and hotels.

Whether to add the extra day before or after the main event depends on factors such as space availability and timing (e.g., the day of the week). Scheduling before the main event means that attendees are still fresh and enthusiastic. Scheduling after the main event enables attendees to deepen relationships they may have just formed.

Note: Scheduling a Hack-on MDN-event during another conference or event has historically not worked well; attendees are typically more interested in the main event, and don't have blocks of time to concentrate on hacking.

Promote the event

Even if your event is open to the "public", you should invite a few key people whom you know will participate. Work with them when selecting dates, to ensure that they are available during the chosen dates. If these folks are well-known experts in the topic, you can to use their involvement to help promote the event.

For public events, identify existing groups that have an interest in the topic. If the Hack on MDN event is connected to a conference, the conference attendees are an obvious pool to tap. You can also, for example, promote it to local web-developer meetup groups in the area where it will be held. Send an announcement through whatever channel is appropriate to that group, in addition to any other general promotion you do.

Use the social media channels that are appropriate to reach your target attendees. We have found that for Web developers, this means Twitter, more than Facebook or LinkedIn. However, popular channels can vary geographically (such as Orkut in Brazil). Reach out to a few well-connected people who have a large following among your target audience, and ask them to re-share your posts.

Budget and resources

You need to figure out how much the event is going to cost, and where the money is going to come from. If you have sponsorship, you may be able to expand your budget. However, it is possible to boot-strap an event by finding free or donated space, and asking participants to pay for their meals and other expenses.

To request sponsorship from Mozilla, submit a Developer Events Request Form, following the developer events request guidelines.

Costs to consider in your budget include:

• Meeting space
• Travel and lodging (for attendees you are sponsoring)
• Food
• Fun

Meeting space

If your event is connected to another larger event, space may already be taken care of. Or, you may need to pay for extra time in the same venue as the larger event. Otherwise, there are lots of options for meeting space. If you are in a city with a Mozilla office, you can request to use the community space in that office. Elsewhere, options include meeting rooms in libraries, churches, coffee shops, or businesses where you have contacts. Many cities now have coworking spaces that rent their conference rooms for a reasonable fee.

Be sure that your venue has good chairs and tables, and reliable power and Internet access. Sitting all day on a bad chair is not just uncomfortable; it can lead to injury. Make sure that the number of attendees and their computers and devices does not overwhelm the power supply and available Internet bandwidth. Be generous (but not dangerous) with extension cords, and if necessary, international plug adapters. A projector for shared viewing can be very helpful. Whiteboards and sticky notes are great for brainstorming and planning.

Travel and lodging

Typically, travel and lodging costs are self-funded by attendees of the event. However, if you have funding to be able to pay these costs for participants who might not otherwise be able to afford to attend, doing so can broaden the range of perspectives at the event. You can also enable more participation by partially reimbursing costs for attendees.

Food

Attendees need to eat! Make arrangements for food during the event, and inform attendees whether meals are included. If your venue allows, have snacks (some healthy and some not) available between meals. If nothing else, make sure there is coffee!

Fun

Allow time for social activities. These can be informal, like going for a hike together, or more formal, like a tourist excursion. Going out for drinks is usually a winner; be sure that non-alcoholic options are available. On the other hand, don't plan every hour of every day. Everybody needs some down time, especially introverts.

Registration and fees

Have a way for participants to pre-register for the event, so that you can have an estimate of the number of people you will get. You can limit the number of registrations if your space is limited; or you can book a larger space if the response exceeds what you initially planned for. If the Hack-on-MDN is connected to a conference, work with the conference organizers to see if an option to sign up for Hack-on-MDN can be included in their registration process.

Keep in mind that you will need one co-leader for every 12-15 participants, and that 30-40 participants is about the maximum number that can be easily handled.

It is a good idea to charge a nominal fee, to discourage people from registering but then not attending. An amount that roughly equals the per-person food budget is reasonable.

Make sure that your registration process sends a confirmation of the date and location, and includes reminders of what to bring, especially one's own laptop.

During the event

Planning the work

Ahead of the event, once you know the topical focus, you can collect tasks that can attendees can work on during the sprint. There may be generated lists that can be helpful, such as lists of pages with a particular tag or flag, or bug reports, etc. Or you might collect items that need to be worked on into a spreadsheet for tracking purposes.

At the start

Be sure to make an introduction at the start of the event. This need not be formal, but be sure to introduce leaders of the event, point out logistics like bathrooms and emergency exits, and mention the Code of Conduct for the event. (Mozilla-associated events are governed by Mozilla's Community Participation Guidelines; the shortlink is https://mzl.la/cpg ). Have attendees briefly introduce themselves and state what they're interested in working on, so you can help them find others to collaborate with.

Tracking tasks

Have a way to track what tasks need to be worked on, who is doing what, and what has been completed. A Google Doc or etherpad can be good for this purpose.

Often, people want to help but don't know where to start, and deciding among many options takes too much mental effort. For any given participant, give them a couple of possible tasks ("you could do A, or B"); this simplifies their choice, without making them feel like they're being bossed around.

Collaborating

One of the benefits of in-person events is that people can work together in ways that they might not be able to when they're not in the same place, for example, by working out ideas together on a whiteboard or by brainstorming with sticky notes.

As an organizer, look for common interests among the participants and for ways that they can work together. If everybody works solo the whole time, they could have equally well stayed at home.

Celebrating accomplishments

Be sure to take time to celebrate accomplishments at the end of the event. This gives participants a better feeling than when the event just ends without any summary. If possible, have people "demo" what they have done, even if it is just showing a new article page.

After the event

Share the event accomplishments via a blog post, to celebrate publicly in addition to the demo at the end of the event.

Finally, also thank participants individually, via email, with a personal note about what they contributed. This both helps them feel appreciated, and encourages them to continue with what they started during the event.