Contribute/Coding

Steward

Dietrich Ayala, Kyle Huey, Brian Bondy and Josh Matthews

Coding Contribute Group

Meetings every Wednesday at 1 pm pacific.

• Next meeting: Stewards/Coding/Group_01_25_12
• Notes from previous meetings

Action Plan

Goals

Grow number of active Bugzilla user accounts in given area of code.

Potential Contributors

Optimize Existing Channels

Audit existing channels where potential contributors find information (or should be able to find information) about how to get involved and then optimize to make sure the channels are effective.

• https://developer.mozilla.org (which pages) (jdm)

• http://www.mozilla.org/contribute

• http://bugzilla.mozilla.org (dietrich)

• http://hg.mozilla.org (and other repositories?)

• irc://irc.mozilla.org

• https://wiki.mozilla.org/Firefox/Get_Involved (dietrich)

• others???

Notes: get traffic stats for each to prioritize?

Retire Legacy Channels

For an area of the project that has been active for so long, such as coding, there will be many old pages with out of date information on them. For instance, a search of 'mozilla coding' brings up this page on the www-archive.mozilla.org site as the third result and a guide for using CVS as the fourth.

• Retire and redirect any legacy pages in top results for a Google search of 'mozilla coding'

Non-Mozilla Channels

We can also look for volunteers beyond our Mozilla channels. Ideas for that include:

• http://meta.stackoverflow.com/questions/114442/open-source-advertising-sidebar-1h-2012
• http://www.ohloh.net
• http://www.volunteermatch.org

Match Volunteers with Opportunities

• Create and maintain a curated list of 50 mentored bugs that can be handed out to promising new contributors as they arrive through the various channels.

• Create processes for manually connecting people with opportunities (eg, pointing someone to a bug in IRC) and for giving people a self-service way to get connected (eg, through the Bugsahoy tool).

Active Contributors

Have a plan for getting newly active contributors into the phonebook and use relevant tags (ex, firefox, javascript, mobile, etc). This will allow us to reach out to experienced contributors with specific opportunities as they come up (for instance, you could email everyone with a 'javascript' tag if you were looking for help with a complicated javascript engine bug that wouldn't be a good fit for new contributors). We may want to document a set of tags we'd like people to use.

Create a process for using the contributor map and contribution trends Mercurial patch dashboards. For instance, have a plan to reach out to any previously active contributor that hasn't been involved in the last two months to learn why they left or help them get involved again.

Amplify the signal of first-time patches - email headers, pulse feed, IRC bots, and more!

Recognize significant contributions with swag, trips/meetings, etc.

Core Contributors

Audit and update the existing module ownership information for coding modules. Identify process for recognizing new contributors and creating new modules/owners/peers.

Background Information

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.

• 0. Open a new Bugzilla account.

• 1. Verify bugs that are already posted, post comments to indicate your findings.

• 2. Submit new bugs even if you are afraid they may be invalid or duplicate.

• 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 a copy of the source code and build it (Find out how from the Developer guide above).

• 5. Get assigned to your first bug

• 6. Create a patch for your first bug

• 7. Get a code review for your first bug.

• 8. Get your patch pushed to mozilla-central.

• 9. Ticket Closed

You should also join IRC in the #developers and #introduction channels. Once you are ready, contact gerv for editbugs privileges

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?

• It would be nice to have tighter integration of mozillians.org and Bugzilla. It would be nice to automatically create groups based on the sections Code contributors submit patches to. For example if I submit a lot of Toolkit/Application bugs then I would be automatically added to that group.

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.

Perhaps the list of new code contributors can be found by looking at users who have recently been assigned to a task and have no resolved tasks. Then we can track these users to see which ones have not made progress in a month and which ones have. We can ping those users manually in Bugzilla.

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.

• Getting badges on mozillians.org for things like 'compiled code', 'completed first bug', 'completed 10 bugs', etc. would be helpful and a good way to inspire people. It would allow them to add their profile link to their resume to show just how epic they are.