FirefoxOS/Participation

From MozillaWiki
< FirefoxOS
Revision as of 17:32, 27 August 2015 by Arroway (talk | contribs)
Jump to navigation Jump to search

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
  • Tight Feedback loop from Contributors to core developers so we can continually improve our pathways

Non-Goals (yet!)

  • Improving Gecko contribution pathways
  • Improving Gonk contribution pathways

Plan

Phase 0 (complete in August 2015)

  • Start hiring process for a dedicated community manager for fxos code contributions. STATUS: Asked Faramarz about headcount, no commitment to hiring at this time.
  • Form team of Gaia engineers who will spend dedicated time on this project. STATUS: Gregor/mhenretty discussing with mobile managers, got the peoples. Next steps: down below, get them tooled up and on-call schedule.
  • MDN document review: Ensure existing docs are correct. STATUS: Gaia team to did a first-pass on the main contribution docs. Existing docs are good, even the architecture bits.
  • 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
  • Design a plan for re-opening Github issues STATUS: Ongoing, moving to Phase 1 for completion. See below.
  • Design a Flame-for-patches-landed program STATUS: Not as many Flames as first thought. Instead, going to give out at events, identified contributors. dietrich posted to b2g-internal and we now have a large number of Flames shipping out to contributors.
  • Create Gaia contribution pathway page: Single page with sequential steps from zero to patch-landed. STATUS: Dietrich started outline, solicited input from Gaia team. Working with MDN to get collapsible content areas added to the site. Once that's working, can fill it in.
  • Identify automate-able contributor activity monitoring. STATUS: not done, next on dietrich's list
  • Identify developer papercuts
    • STATUS: not done. need to find those threads/etherpads about this over the years.
    • Regular Papercuts bug, Developer Papercuts bug, Dale's bug
    • Next steps: Find threads, etherpads, make one list, prioritize, fold into plan - OWNER: dietrich will do the research, then Gaia team can analyze for priority.
  • Get feedback from existing contributors
  • Merge dev-gaia and dev-b2g mailing lists into
  • Merge #gaia and #b2g IRC channels
    • mailing list first, the IRC
  • Figure out how to get more developer devices into people's hands (Flame and z3c)

Phase 1 (complete in Q3)

  • Consensus on a desktop development environment
  • Design a double-click+F5 workflow
    • STATUS: not started. some existing recent discussion on dev-gaia. need to put Gaia team stakeholders together to draft a plan, then push out to dev-gaia for feedback
  • 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
  • Design a plan for re-opening Github issues. STATUS: In progress, owned by mhenretty; https://etherpad.mozilla.org/reopen-github-issues.

Phase 2 (complete in Q4)

  • Release strongly-supported desktop development environment
  • Release a double-click+F5 workflow
  • 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
  • Developer Support
    • Numbers of answered SO posts
    • XDA-developers
    • Reddit
  • Documentation
    • Maybe num visits to the contribution pages?
  • Evangelism
    • Talks
    • Videos
    • Visits to assets

Signposting

TODO: Add all this to main B2G wiki page (where else?)

  • Product direction/vision
    • Roadmap
    • UX Specs
    • Where to submit requests/ideas
  • Product development
    • All dev docs
    • All communication points
    • Where can I find something to work on, or figure out if what I want to work on will be accepted
  • Release management/status
    • What release are we on, what's next
  • Testing
    • Where can I get a build, and for what device
    • Where can I submit bugs
    • How can I manage my builds (backup, restore, OTA)

Needs Processing

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

Ideas

  • Gregor suggested making videos for ‘My first FxOS app’, ‘My first FxOS add-on’ or ‘My development workflow', after seeing Reza's deck. We should publish through Hacks Youtube channel.

Notes

Existing docs and workflows

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?

Contributor Types

  • Gaia
    • Experience: Web developer
  • Gecko
    • Experience: C++, JavaScript, build tooling
  • Gonk
    • Experience: C, C++, build tooling
  • Device Porting
    • Experience: C, C++, Android dev, build tooling
Retrieved from "https://wiki.allizom.org/index.php?title=FirefoxOS/Participation&oldid=1092336"