Apps/Project Plans
Initiative: "Firefox Mobile Apps v1"
This initiative is about Apps running on Gecko. It pushes us again toward our goal of bringing open web apps to all the users of the web. Apps for 300 million desktop users, 25 million+ Mobile FF users, and millions of FxOS users.
For Developers, "Firefox Mobile Apps v1" will simply provide a gateway to the global audience and momentum of Firefox Mobile. Developers can begin to grow at the rate of deployment of FxOS, pacing with Android, creating apps with all the powerful features that users expect from native apps; empowered with all the benefits of the open web, supported with the structure and services of a traditional marketplace. It's time to bust open the gates, and share with millions of developers the amazing opportunity we see.
Why "Firefox Mobile Apps v1":
- Developers - Apps run on multiple platforms; use the same API's, packaging and privileges.
- Mozilla - gecko consistent on all platforms
- End-User - my Apps work on all my devices, pay once
- Operator - remove control point, keep direct to consumer model
Goals for the "Firefox Mobile Apps 1" initiative
- Provide working proof of Open Web App principles: the app manifest as security model
- Provide working examples of groundbreaking web APIs on Gecko
- Provide delivery vehicle for cross-platform apps (Privileged & Packaged apps on Android, Marketplace)
- Provide flexible business model for the delivery of apps by others (Payments)
Target Audiences
- Nightly Fennec
- Aurora Marketplace
Scope: Minimum Viable Product
Parity with FFOS
- Implement an app (Kitchen Sink) that showcases the APIs and features supported by the WebRT across supported platforms (FXOS, Android).
- Implement must have APIs, specifically those privileged apps that we support on B2G / FFOS
- Implement support for packaged/privileged apps on Android in Nightly.
- security model : apps manifest as key to security model
- download, install, update, uninstall
- server certified packaged apps
- User Experience of using Firefox Apps on Android
Duration
March 6, 2013 - September 6, 2013
Projects
list any sub-projects - depending on complexity you may want to create a project page for each sub-project
Sub-project
at a minimum, a sub-project should have a name and description. it may also include a link to the project page or inline text for a simple sub-project.
Communication
| Communication Type | Mechanism | Audience |
|---|---|---|
| Announcements | dev-platform and dev-planning lists | all |
| General discussion | dev-platform list | devs |
| Meetings | meeting time
|
all |
| Meeting summaries | this wiki | all |
Press & Blog Posts
optional - you may want to capture press, blog posts, etc. about the project
Minutes and Progress Reports
| 2012 | |
|---|---|
| |
People
list required competencies for people and, once defined, the people working on project. note that not all of these competencies will be required for every project
| Project Champion | |
| Program Management | |
| Product | |
| UX | |
| Engineering | primary devs working on project |
| Other Engineering | subject matter experts contributing to project |
| Accessibility | |
| Localization | |
| Services | |
| Incoming Bug Triage | this may be someone listed elsewhere, the key is to list people who handle triage |
| QA | |
| Security | |
| Privacy | |
| Releng | |
| Marketing | |
| Legal |
Milestones/Iterations/Tasks
high level milestones can be included in this page. more complex milestones and tracking information (typically bug lists) should be included on a milestone specific tracking page
Dependencies
feature, partner, resource, etc.
Risks
list risks in table below. assign a unique risk id to each risk. for ex., the project plan template may define risk ids prefixed with PPT like PPT001.
| Risk ID | Description |
|---|---|
| PPT001 | Sample risk |
References
other references, very useful catch all category for existing links and text when cleaning up existing project pages