Summary of Contributor Engagement threads on dev-planning

There have been a few threads regarding Contributor Engagement on the dev-planning list, focussing specifically on contributions to the tree. In order to follow up on these ideas, and others that different folks have been brewing, we’re discussing this in a session during the All-Hands next week.

Challenges for contributors

  • What does a new contributor have to go through to build FF:
    • no readme
    • —enable-application=X
      • no warning
      • needs default
    • directory is called mozilla-2.0, not firefox4.0
    • cvs is mentioned in the docs!
    • build instructions prose is poor
    • not configure/make based
    • ac_add_option / .mozconfig is confusing
    • patch submission is tortuous
    • even simple stuff has jargon
  • Getting feedback:
    • there isn’t a good wasy to ask “what do you think of this approach?”
      • f? only works on attachments
      • some people put the proposal as an attachement, then ask for feedback
      • there was a suggestion of a ‘request review’ mailing list.
  • Tinderbox is scary:
    • new contributors are scared by oranges, and we currently have a problem with random oranges
      • there is automated oranging, sufficient?
      • ArbPL might be easier in this regard
  • Submitting bugs:
    • finding a committer is tough
      • we should have a script/query/dashboard following [commit-needed]
      • add a “job” like sherriffing, for the person whose job it is to land patches
    • getting tryserver access takes a day
      • arbitrary try server access
        • solvable, but security concerns
    • we’d like to prioritize landing from new contributors and “people who aren’t paid to work on this thing”
    • currently work has to be ‘negotiated’ into the tree
      • new contributors should have ‘greased path’ into the tree
  • So many tools to learn:
    • tbpl
    • tryserver
    • qimportbz
    • bzexport
    • gdb-archer
    • lithium
    • irc
    • mercurial queues
    • bugzilla fastness
    • weird unique build system – autoconf213, mozconfig
  • Time zones:
    • hard to get an answer if you contribute outside 9-5, Monday-Friday PST
  • Working independently: Problems should be solvable for external contributors independenctly. Each new person who is introduced can potentially scuttle what you’re doing. If you email someone and wait a week for a response, it makes it less fun. If they never respond you’ll probably stop contributing. Related: tryserver access, reviews, approvals, commit-needed

Experience reports

  • Long form:
  • briefly:
    • seamonkey does a lot of hand-holding, and has been successful
    • l10n too
    • Gnome Love project
      • (gnome-women is also copyable)
    • maybe get reports from professors, Seneca, etc
      • relationships are more important than resources
      • you need to “protect” new contributors from “normal” interactions
  • Experiences summary:
    • idiosyncratic build infrastructure
    • submission process (including bugzilla)
    • contributor agreement
    • r? with no target are ignored
    • requesting reviews
    • learn irc, our channels and etiquette
    • blame logs
    • finding related bugs in bugzilla
    • [checkin-needed]
    • project branches
    • watching the tree + tinderbox
    • approvals process
    • blocking/wanted flags
    • forgetting the -u flag [editor’s note: NEVER EVER FORGET THE -u FLAG!!!]

Engagement

  • Contributor engagement team (ref David Boswell)
    • high level, need coding-specific help
    • 100 people contact per week to help
      • mozilla.org/contribute -> contribute@mozilla.org list [needs volunteers to answer the queries - contact david@mozilla.org]
      • contribute@ list and canned responses
      • poor success ratio (10% is a good result)
      • getting started information
      • #mozillians channel
      • track what works and doesnt
      • point them to first bugs
      • contributor directory can help
  • Mentoring:
    • we should have an outreach team
    • mentors would guiding patches through the process
    • danger: watch out for people not going the distance
    • people who learn processes will be good in the long run
  • What do we do when potential contributors email existing contributors directly?
    • mentor?
    • send canned response?
    • redirect to Constributor Engagement
  • terminology is important:
    • “internal” vs “external” – “internal” might have bad connotations
    • volunteers is bad
    • “greased”?

Tools to help us

  • we need dashboards to find:
    • unspecified r?
    • forgotten [checkin-needed]
    • patches from new contributors
    • [good first bugs]
  • identify new contributor (metrics):
    • age of bugzilla account
    • number of patches submitted by this submitter
    • whether a submitter is employed by Mozilla Corp
    • whether a submitter is paid to work on Mozilla
    • age of submitter’s first-ever patch
    • timezone of submitter
    • native language of submitter
    • age of submitter
    • number of bugzilla comments written by submitter
    • whether a submitter has commit privs
    • fuzzy heuristic combinations of the above to bucket people into “new unpaid volunteer” or whatever
    • dmose/metrics have built something like this
  • development appliance?
  • documentation:
    • live help?
    • feedback button (there is a talk page – is that the same thing>)
  • a stackoverflow instance like infomonkey for mozilla questions

Documentation

  • Is this just a documentation problem? [editor’s note: No]
  • many docs are obselete
    • the important ones are the ones which appear high on google
    • hard to update
    • updating guidelines

About Paul Biggar

I'm a compiler geek, with a slant towards scripting languages. I work on the Javascript team at Mozilla. Before that I did a PhD in compiler optimizations, static analysis and scripting languages.
This entry was posted in Uncategorized and tagged , . Bookmark the permalink.