Firefox OS Projects

Deliverables

• All projects should deliver a written summary containing the project results and findings, and feedback on the project, process, and technologies used.
• Any code created as part of the project should be in a public GitHub repo, licensed under the MPL.

Contributors/Programs

Types of programs and contributors

• Individual contributor
• Academic contributors
  • Undergraduate team project (Capstone)
  • Undergraduate/Vocational large programs
  • Graduate researchers
  • Special programs (GSOC, OpenAcademy)
• Partner engineers
  • Working on core OS features
  • Working on R&D for apps/features specific to a market

Designing Projects for Success

• Avoid release-critical work: These projects should be areas that we know our core OS engineering groups will not be able to work on in the 3-6 month timeframe. The nature of student and other unpaid contributor activity means the timelines are often unpredictable.
• Ignore internal systems entirely: The complexity of Bugzilla and the Mozilla software development lifecycle is always underestimated. For these projects, use Github/Wiki/Etherpad. Contributors who continue on with more projects will eventually learn these systems, but it shouldn't block their productivity at the start.
• Do not make “landing” a goal: Landing code in Mozilla projects is always harder and takes longer than anyone estimates, even those who've been doing it for many years. These projects should be designed to get as much done as possible *without* landing, and leveraging every possible feature and deployment path to get the code/findings available without having to land it in the core. If we do decided to land the feature in the core, the paid employees can help the project along from that point, doing the unfun stuff like automated unit/integration/performance tests, etc.
• Have clear requirements: Your project should clearly define the concept, as well as the skills and technologies are needed.
• Have a clear outcome and deliverables: Define a success condition. For researchers, this might be an answer to a question, with accompanying research materials, code samples or collected data. For developers, this might be user stories, test cases, specs/mockups, and prototype code.
• Regular check-ins: Have a weekly or bi-weekly meeting. Regularly scheduled communication avoids projects from heading too far in the wrong direction, or falling too far behind.
• Create Incentives: For example, for academic groups ensure the work is being done for credit as part of a formal program.