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.
- there isn’t a good wasy to ask “what do you think of this approach?”
- 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
- new contributors are scared by oranges, and we currently have a problem with random oranges
- 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
- arbitrary try server access
- 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
- finding a committer is tough
- 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
