FirefoxOS/Participation

Problem

• Developing the core of Firefox OS is too hard
• Gaia does not have a supported development environment
• Contributor first-time experience is poor
• Navigating the dev->test->review process is too hard for contributors

Goals

• Vibrant and engaged development community, invested in the success of Firefox OS
• Clear and managed developer pathway for new contributors
• Supported and clearly documented development environment for Gaia
• An F5-style developer workflow for Gaia
• Bugzilla-less code contribution pathway for Gaia

Plan

***DRAFT***

Phase 0 (complete in July)

• Start hiring process for a dedicated community manager. STATUS: Asked Faramarz about headcount.
• Form team of Gaia engineers who will spend dedicated time on this project. STATUS: Gregor/mhenretty discussing with mobile managers.
• MDN document review: Ensure existing docs are correct. STATUS: Asked Gaia team to do a first-pass on the contribution docs.
• Create Gaia contribution pathway page: Single page with sequential steps from zero to patch-landed. STATUS: Dietrich started outline
• Start regular triage of UX items to unblock and open up design issues STATUS: Tif is doing weekly triage sessions w/ the UX team, Dietrich is joining.
• Begin discussion about Gaia dev environment STATUS: owned by the Jonas Task Force
• Begin discussion about a double-click+F5 workflow
• Design a plan for re-opening Github issues. STATUS: In progress, owned by mhenretty; https://etherpad.mozilla.org/reopen-github-issues
• Design a Flame-for-patches-landed program Not as many Flames as first thought. Instead, going to give out at events, and have core team identify contributions worthy of Flame and relay to Dietrich for delivery.
• Identify automate-able contributor activity monitoring
• Identify developer papercuts

Phase 1 (complete in Q3)

• Consensus on a desktop development environment
• Regular schedule for on-duty for IRC/lists by community team
• Re-open Github issues on Gaia
• Identify and expand other active contribution areas and begin monitoring - StackOverflow, Reddit, XDA-Developers, etc
• All apps have style, contribution and developer workflow info in their README files
• Work with managers to prioritize fixing the developer papercuts we identified
• Update the Contribute from mozilla.org/contribute to point to the right links

Phase 2 (complete in Q4)

• Release strongly-supported desktop development environment
• Bugzilla-less development flow through Github issues
• Expand Stackbot to cover more than just StackOverflow, for automated monitoring and notifying on more contributor activity

Metrics

Brainstorming

• Code
  • http://areweeveryoneyet.org/ for...
    • total numbers of staff vs non-staff code contributors
    • patches from staff vs non-staff code contributors
• Developer Support
  • Numbers of answered SO posts
  • XDA-developers
  • Reddit
• Documentation
  • Maybe num visits to the contribution pages?
• Evangelism
  • Talks
  • Videos
  • Visits to assets

Actions

Open

• Faramarz: delivering queries for backlog bugs.
• Faramarz: said someone had list of bugs where contributors failed.
• Dietrich: Contact Vishy about his papercut-like items (no reply yet)
• Mhenretty: working with managers to select community team
• Dietrich: reach out to MDN to do a review of existing docs

Needs Processing

• Integration tests are broken, cannot run - need to verify
• Building on Mac OS X is maybe broken, unclear - need to verify

Notes

Existing docs and workflows

• Gaia (MDN)
• Code Repository READMEs
  • dev workflow README

Developer papercuts

• Desktop tools should work with double-click-to-open, not only command line pointer to profile
• Case-sensitive filesystem - container for solution?
• Mac build env broken - work with releng to add a build test to catch that regressing?