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_03_07_12
• Notes from previous meetings

Action Plan

Goals

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

Channels

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?

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

Offline Channels

How can we use events as offline channels to help people get involved?

• Leverage the ReMo program -- help bring in more technical Reps and help non-technical Reps promote coding opportunities by creating material for them to use (videos, hand-outs, etc.)

• Make sure key community events have someone from coding going to talk about how to get involved. For example, see this MozCamp Asia Report post about the effective coding session.

• Create a 'Hot to get involved with Mozilla Coding' flyer that can be handed out at events and made available for people visiting Mozilla Spaces.

Tools

Coding Specific Community Building Tools

• Coding dashboard 1

• Coding dashboard 2

• Note: Ideas for phase 2 of coding dashboards in bug 729703

• Bugsahoy tool

General Community Building Tools

• Phonebook, Task Board, Event Manager

Tools Wanted

Track ideas for tools we want to create to help with community building

Potential Contributors

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.
  • Measure the rate of creation of new mentored bugs, rate of fixing mentored bugs, find out overall percentage of all mentored bugs that have been fixed

• 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).

• Work with other functional areas where there is overlap, for instance people interested in web development can also hack on Firefox.

Training

Provide documentation and other materials, such as videos, that help people learn how to successfully use contribute to Mozilla.

Get more information in front of users without making them search for it:

• Add instructions on how to run Firefox after completing a build (bug 648681)
• Add a .gdbinit to the tree that simplifies common debugging tasks ({bug|184013})

Simplify existing processes to align with systems that are familiar:

• Turn building from scratch into ./configure && make (bug 648701)

Brian is working on a number of coding tutorial videos using Camtasia:

Getting started:

• Overview of the development process
• Creating a bugzilla account
• Getting on IRC, #developers, #introduction
• Confirming an unconfirmed bug
• Verifying fixed bug
• Posting a new bug
• Getting editbugs access
• Installing MozillaBuild & VisualStudio from blank VM OS install on Windows
• Checking out the code, building it and .mozconfig setup
• Finding a first bug to work on, mentored bugs, good first bugs,
• Fixing a bug
• Debugging
• Creating a first patch file with your information in it, mercurial patch queue basics
• Getting a code review, finding out who should review it? What to do when you have no progress getting a review.
• Landing your fixed bug that was r+ed.

Improving what you already know:

• Using pymake for faster builds
• Mercurial patch queue advanced

Advanced topics:

• Using xperf to profile Mozilla code

Automated tests:

• Overview of the types of automated tests
• creating a reftest
• creating an xpcshell test
• creating a mochitest
• understanding/using TBPL view of tryserver results

Presentations

There are lots of presentations out there that we could pull together into one easy to reference location.

• Hacking Gecko presentation at FOSDEM
• Dietrich's Hacking Firefox presentation at FOSDEM (need link)
• From Web Developer to Firefox Hacker

Active Contributors

Key Milestones

The creation of someone's first patch is a key milestone in the coding contributor lifecycle and there are a number of things we can do to make this a better experience for people and to amplify the signal of first-time patches.

• Have an tool that takes the email headers from Bugzilla about first patches and use a Pulse feed to announce that in relevant IRC channels ({bug|721240})

• Have an email sent out to people who have just had their first patch approved encouraging them and giving them key information such as the way to get added to credits, how to make sure the patch is landed, how to find other bugs, etc.

• There may be other key milestones where we want to do something similar. We should audit all of these steps and identify where else we want to make changes. (bug 722338)

Recognition

Take the current ad hoc process of recognizing active contributors with swag, invitations to events, etc and create a scalable process for identifying and recognize key active contributors. For example, Josh maintains a manual list of people he is encouraging but that isn't very scalable.

Phonebook

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.

Dashboards

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.

Use the Get Involved dashboard along with Bugzilla data to determine a conversion ratio to measure the effectiveness of our matching processes of bringing in new contributors.

Figure out how many Bugzilla accounts are correlated with email accounts that were used on the Get Involved page.

Write a tool that determines if a previously-active contributor has stopped being active. (jdm)

Non-IRC venues for questions

Consider a venue for contributors to ask questions about Mozilla-related code: StackOverflow/StackExchange has been discussed before, but didn't go anywhere particularly actionable: {bug|650513}

Other

There's a meta bug with ideas for improving contributor engagement. We should triage this and fit them into the appropriate spots in the action plan.

• https://bugzilla.mozilla.org/show_bug.cgi?id=652719

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.