Websites/Mozilla.org/Archive/Contribute/AllHandsCodingSession

Details

• Wed, April 6, 2:00 PM Pacific
• Very Good Very Mighty (3rd floor, near JS pit)
• Conference call: extension 8605
  • 650-903-0800 x92 Conf# 8605 (US/INTL)
  • 1-800-707-2533 (pin 369) Conf# 8605 (US)
  • The number is stolen from the platform meetings, so ask on IRC if you have a problem
  • join irc.mozilla.org #mozillians for back channel

Suggested Reading

Summary of last week's discussions on dev-planning

Experience reports

• https://live.gnome.org/GnomeLove
• https://wiki.mozilla.org/Firefox/Projects/TabCandy/Work
• http://www.joshmatthews.net/blog/2010/03/getting-involve-with-mozilla
• https://wiki.mozilla.org/JavaScript:New_to_SpiderMonkey
• https://groups.google.com/group/mozilla.dev.planning/msg/ea66ebfa2061d888
• https://groups.google.com/group/mozilla.dev.planning/msg/d0bbd32c1139af92
• https://groups.google.com/group/mozilla.dev.planning/msg/f49f0a96e6ab86dd

Agenda

Discussing improving engagement with new contributors, specifically related to coding and the Mozilla tree.

Contributor engagement funnel

• good first bugs
• mentor assignment
• landing page

experience reports

• seamonkey?
• l10n?
• tabcandy?
• ckaiser?
• sfink?
• jdm?
• paul biggar
• others?

Mentoring

• how-to documentation
• experience reports
• volunteers + volunteer page

Documentation

• beginner documentation
• getting started with the tree
• formats (MDN?)
• tools listings + guides

metrics

• r?
• [commit-needed]
• contributors needing responses
• Metrics/dmose have a metrics dashboard

Pain points

• make -f client.mk build
• mozconfig
• enable-application
• directory name
• unassigned r?
• turning point of finding the right committer
  • document this
• fear of claiming bugs
  • bug squatting
• tryerver access
• outside "regular work hours"
• bugzilla
• following progress/workflows

• removing bottlenecks
  • tryserver
  • reviewers
  • approvals
  • [checkin-needed]
  • contributor agreement

• -u flag (!!!)

volunteers!

• (any tasks not have a volunteer?)

collaboration

• mailing list/irc
• future meetings
• bugzilla category/tracking bugs

Minutes

Purpose

We want to go from where we are currently, where contributors are few outside of Mozilla's core, to getting more community contributors.

People in attendance

• Axel, on board of Mozilla Europe, wants more international contribution
• Jonas Sicking, wants contributors
• Janet Swisher, works on developer documentation
• Pat McBenice, works on networking, wants efficiency
• Gandalf, works on local communities, on board of Mozilla Europe, interested in human motivation
• Kash, works on imput, wants to get involved with Mozillians project
• Bill Hue(?), metrics, wants better data more available
• khuey, wants more peers
• Joi, metrics, interested
• Sheppy, documentation
• Paula, metrics, designs dashboards
• Tiago, metrics
• Mohammed(?), metrics
• David Boswell, engagement, wants to help contributors get information
• Andrew McCried(?), wants to see process for new developers
• Jeff, automation and testing team, interested in leveraging community, interested in play between add-ons and core
• Jennifer Zuckerman, Mozilla Messenging, wants to steal ideas
• Nelson, metrics, wants to better give data
• Daniel, manager of eng metrics, metrics is here because we've been working with Dan Mosedale on concepts to measure contributor engagement and how to encourage people
• Jeff/Waldo, hacks on javascript, encourages new people

Ownership decisions

• People to look for and help mentors - David said he could own half of that. jdm and David Boswell say they can help with this also.
• Curate peer/owner list - talk to gerv, who's worked on this before, but it's too big a task for one person
• Owner for good first bugs/student projects - khuey
• Owner for updating peers, talk to gerv and owners, email owners and peers, represent our interests in this - Jonas Sicking

First impressions

Right now, new contributors go to contribute site, dig into area they're interested in. There's static info there, you can drill down. (David)

We're trying to take two approaches:

• provide info people need
• put people in touch with people they can help

Once the connection is established, we want people to feel a part of the community, ask questions, start a mentor relationship.

Point people available to answer inquiries for different project area: https://wiki.mozilla.org/Mozilla.org/Contribute/Old#Point_People

We want to build a self-helping community, where older people help the newer ones. Often, the person who mentors does not need expertise in the field. One can help someone find answers even if it's not specifically the area they work in. We have Mozilla context knowledge that's not written down. The information on wikis is out of date. (Gandalf)

Key is giving people specific tasks (David)

Problems with current contribution

• Good First Bugs are good, but even figuring out how to fix a trivial bug requires large amounts of commitment from new contributors

• If everyone had one mentor that they could feel free to ask stupid questions, it would be very valuable (Paul). Asking stupid questions in dev channel is a waste of everyone's time, asking a mentor is appropriate (Gandalf)

• Infomonkey is a stack overflow instance for Spidermonkey - it's a Q&A site. We need that across coding at Mozilla so you can ask a stupid question or see that someone has already answered it (Paul).

• We need a new channel where developers can just go to ask stupid questions (humph)

• Beware of community anti-patterns - good systems can backfire. Being able to ask stupid questions can lead to help vampires - people who just ask same questions. Some ways to help - encourage newbies to answer east questions, teach newcomers how to search for answers (Axel)

• We need someone to look for and help mentors. David said he could own half of that. jdm and David Boswell say they can help with this also.

• Good First Bugs (GFB) has serious problems. It's either simple things that would be good first bugs, or a dumping ground for things the filer doesn't have time for. (khuey) It has some that are out of date or not for Firefox. (jdm) GFB is sometimes used as an excuse to not help people - just send someone a link if they ask what they can do. A lot don't make it through. (Gandalf) Some contributors want to be left alone and figure things out, but others want lots of help. (Paul) A big group is developers who just want to scratch their own itch. (Wes)

• https://bugzilla.mozilla.org/buglist.cgi?quicksearch=student-project is another good resource for new contributors. It's meant to allow classes to pick up bugs.

• http://www.youtube.com/watch?v=QRebjdMabao Showing first dashboard which looks at commits in Mercurial. In the video, the histogram and table shows usernames and the commits they did. We should be embracing people who just did their first patch. We're working on metrics now to show how long patches wait for review.

• Community metrics mailing list: http://groups.google.com/group/moz-community-metrics

• The Phonebook project will help us keep current emails of people. (Daniel)

• Existing dashboard: https://metrics.mozilla.com/pentaho/content/pentaho-cdf-dd/Render?solution=community&path=%2Fdashboards&file=contributorMap.wcdf

• Don't tell module owners to declare peers. They are too busy. (timeless)

• A barrier to contributions is helping first contributors find someone to review their first patch. We need to provide info on who can review. (Paul) Our new dashboards are more leader-oriented. (David)

Documentation

• There's no good documentation for newbies telling them how to get to first patch (Paul)

End of meeting

We ran out of time, and didn't discuss many things (esp docs), and didn't get owners for some things. Discussion will continue on mozillians@lists.mozilla.org.