Steward

Dietrich Ayala, Kyle Huey, Brian Bondy and Josh Matthews

Contribution Paths

What are the steps someone can take to get involved in your project and learn enough to be able to start scratching their own itch?

1. Submit

2. Verification

3. Triage

4. Assignment

5. Patch Coding

6. Code Review

7. Security

8. Patch Release

9. Ticket Closed

What goals does your team have for bringing in new contributors to your project area?

Proposed goal: Create and maintain a curated list of 50 mentored bugs that can be handed out to promising new contributors.

Sub-proposal: Ensure some sort of distribution across lots of components?

What data is available to measure if we're meeting your goals?

Have a way to determine skill level and tailor the path appropriately. For instance, someone who can compile Firefox can be given different tasks than someone who is just starting out with coding. We could add a field to the current Get Involved form when someone says they're interested in coding and ask a specific question about a skill level.

Adding coding activity to a mozillians.org profile will make contributing more attractive. Things to consider including are: A list of resolved bugs in bugzilla or else a ist of patches committed and authored would definitely help. Perhaps integration with open badges as well.

Give mentors the tools to be successful -- a guide to when and how to contact someone to learn why they did or didn't complete a task, etc.

Where are the high quality code contributors? Currently I think we wait for people to come to us. This may not be the highest of quality leads that are available. I think we should try to get an ad on StackOverflow to find new contributors. I think we can also look at cross-promotion opportunities inside Mozilla. For instance, the Mozilla Developer Network has an audience that covers people who aren't regular contributors and that could reach new people.