Contribute/Coding
Steward
Dietrich Ayala, Kyle Huey, Brian Bondy and Josh Matthews
Identify Community
Q: Can you identify all of the contributors on your team (both paid-staff and volunteer-staff)?
A: Yes. A good place to start is to look at the Contributor map and Contributor trends metrics page. This list shows all members who have contributed at least one patch to the tree.
It does list whether the member is paid-staff or volunteer-staff but if is probably not fully accurate. It is hard to tell from the metrics page if the members are still active or not. Active contributors can usually be found on #developers of IRC though.
Suggestion: Use the mozillians.org contributor directory to help. Communicate through your team's channels and encourage people to sign up and group themselves with a common team tag. If you assign a group tag to all contributors on your project, the Mozillians dashboard will track the size of that group and will also allow you to easily export the contact information for group members. You can export these contacts to ensure all your contributors are signed up.
Define Contribution Opportunities
Q: Can you point someone interested in contributing to your project to a list of available contribution opportunities?
A: There is a big list of good first bugs for those interested in coding. It may sometimes be easier to simply browse bugzilla though to find an exact section that interests you most and then find a bug within that section that you think you can handle.
Suggestion: Look at what your team's needs are and what gaps you have in staffing to come up with a list of contribution opportunities. Capture those on a wiki page, in bugs, as role descriptions in Jobvite or whatever makes sense for your community.
Map Contribution Paths
Q: Are there clearly understood steps someone can follow to go from knowing nothing about your project to successfully contributing?
A:
Every new coding contributor should be pointed to the MDN developer guide. A couple first goals should be to get familiar with Bugzilla and to build the source code.
- 1. Verify bugs that are already posted
- 2. Submit
- 3. Triage incoming bugs to see if they are valid or if they need to move to another section. Watch for incoming bugs in the past 24h on Bugzilla.
- 4. Get assigned to your first bug
- 5. Create a patch for your first bug
- 6. Get a code review for your first bug.
- 7. Get your patch pushed to mozilla-central.
- 8. Ticket Closed
Suggestion: In addition to just documenting these steps, look for a simple 5-minute task that someone can take to get started (for example, signing up for Bugzilla if they are interested in coding) and also figure out where in the process you can add a mentor to help people.
Establish Goals and Metrics
Q: Can you measure participation or contributors today? If so, what metrics can you track? What goal or metric would you like to achieve for Q1? Alternatively, what metrics would you like to get in place for Q1?
A:
- 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?
JDM wants to collect a list of new code contributors, adding to it every time we spot a newcomer in bugzilla. We could then write a script that would check how long it's been since they were last active in bugzilla, and be able to follow up if they disappear.
Suggestion: Write down what you think would be helpful to track even if it isn't possible to get that data today. We'll work on implementing dashboards when we know what data we want.
Ideas
- 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.