Contribute/Best Practices

From MozillaWiki
Jump to: navigation, search

This page documents best practices about how to help new people get involved with Mozilla.

Local Community Best Practice Sessions

Local community leaders have been sharing their best practices at the Grow Mozilla meetings and the videos and slides from those are available here.

Provide Recognition

Consider recognizing someone's contribution--this can be something simple but is probably the most effective way to keep people interested in giving their time to the project.

Examples:

  • List someone in the Friends of the Tree section in the WeeklyUpdates
  • Comment in a fixed bug to say thanks
  • Nominate someone to be a module owner or peer
  • Create a new role in your project (eg, if someone likes to help new people get started, make them the Onboarding Lead)
  • Badges

Create a 5 Minute Task

Consider creating a five minute task that is an easy introduction to your project for new contributors to give people a chance to get their foot in the door.

Not only will this help new contributors, but it will help you too. If someone says they are interested in getting involved but won't spend 5 minutes doing something, then this is probably not a relationship that is worth spending much of your time on.

Examples:

  • Ask someone to set up a Bugzilla account if they're interested in coding
  • Ask someone to download a nightly build if they're interested in testing
  • Ask someone to grab a download button if they're interested in marketing
  • Ask someone to do copy edits to a web / documentation page
  • Ask someone to join a bug triage project: Bugmasters/Projects

Create a Task of Medium Complexity

Not every task needs to be bite-size. It's perfectly fine for a contributor to want to work on something more complicated, they just need to be given the tools to do so effectively. Good first bugs are tagged in Bugzilla, but still need quite a bit of setup before a beginning contributor can get started. And more difficult bugs tend to have mentors; Mentored bugs are great ways of introducing contributors to more complex bugs in a non-intimidating fashion.

When you’re marking a bug as being good for another person to work on, please take a few moments to dump your investigative work in the bug. Function names, MXR links, steps to reproduce, explanations of the problem and how it can be solved: these are the stepping stones that allow a contributor to start looking into how to solve the problem without waiting to get in contact with you. Tagging something as a mentored bug will feed it into BugsAhoy.

Reach Out

Consider getting in touch with someone and asking if they need help. We have a history of wanting contributors to figure things out for themselves--that's great when it happens but Mozilla can be confusing even for long-time community members.

Examples:

  • If you see someone in Bugzilla with 'New to Bugzilla' next to their name, send them an email
  • If you haven't seen anything from an existing contributor in a while, get in touch and ask if they are being blocked by anything
  • A quick way of seeing if a new contributor has been active in Bugzilla is to google for "site:bugzilla.mozilla.org user@domain.tld"
  • You can also check a bugzilla user activity report with a user's email: https://bugzilla.mozilla.org/page.cgi?id=user_activity.html

Offer Incentives

Consider providing something to contributors to thank them for something they've done or to get them excited about an upcoming event or activity.

Examples:

Offer Support

Volunteers may need some help in order to help you. You may want to consider if there are specific needs that a volunteer may need help with in order to be effective.

Examples:

  • The Mobile Test Driver program offering loaner phones to people to test Mobile Firefox
  • Providing a headset to both employees and volunteers so they can participate in video team calls

Host Events

Consider having an offline or online event to get people interested in your project together to work on something specific, to plan or just to socialize.

Examples:

Run a Contest

Consider running a contest to encourage contributor participation. Examples:

  • AMO Editor Challenge - A short review queue is key to a good add-on development experience. In this contest, the volunteer editor who reviewed the most add-ons during the contest period won a MacBook Air. The contest resulted in the queues being empty for the first time.
  • Favorite Add-ons Contest - This was a great way to get users to encourage add-on developers and tell them how indispensable their contributions are.

Clarify Ownership

Consider having a very clear understanding of people's roles and of what they own to avoid situations where opportunities are missed when people assume someone else will take care of it.

Everyone in Mozilla shares the responsibility of bringing new people into the project, but that's not to say there aren't specific areas that need to be owned by specific people.

Examples:

  • Who in your project makes a point of staying in an IRC channel to answer questions people may have?
  • Who in your project keeps documentation and relevant wiki pages up to date?
  • Who in your project gets the word out about contribution opportunities and knows about different channels available (newsletters, promos, snippets, feeds, lists, etc.)?

Put those roles and contact information for ownership onto the main wiki page for your project or module.

Create a New User Flow

Consider mapping out how someone interested in your project can find out about contribution opportunities and how to start working on a project. Wiki pages and blog posts are important parts of this, but how will people find those and what should they do next if they're interested?

Don't Get Discouraged

Helping people get involved with Mozilla (or with any volunteer activity) is hard work and you're likely going to fail more often than you'll succeed. Information from traditional non-profits suggest that we should expect a 1 in 10 success rate for bringing on new contributors.

Another thing to keep in mind is that there is a big learning curve and it might take someone a fair amount of time before they start contributing (another reason to create easy ways for people to make their first contribution instead of someone needing to get source code, build it on their machine, find a bug, create a patch, file a bug and then find a reviewer for their first contribution).

So that's all to say, don't get discouraged :)

Retrieved from "https://wiki.mozilla.org/index.php?title=Contribute/Best_Practices&oldid=1017143"