|
|
| Line 44: |
Line 44: |
| * Platform technologies (e.g. Should Mozilla offer an API to XYZ?) | | * Platform technologies (e.g. Should Mozilla offer an API to XYZ?) |
| * User Privacy & Identity (e.g. Should Mozilla promote initiatives such as AttentionRecorder? OpenID?) | | * User Privacy & Identity (e.g. Should Mozilla promote initiatives such as AttentionRecorder? OpenID?) |
| * Media Integration (Is there a new UI we can introduce for sharing, discovering videos, photos?) | | * Media Integration (Is there a new UI we can introduce for sharing, discovering videos, phot |
| * etc...
| |
| | |
| In this process, we expect to learn a lot from both the successful and unsuccessful projects. The feedback will be documented incorporated as lessons into the product development process. The proposed evaluation process will ensure that we do not over-invest in an area without a clear outcome.
| |
| | |
| == Tools ==
| |
| | |
| It is recommended that a separate operating environment be setup so as to not encumber existing production tools and codebases.
| |
| | |
| * Mini website (labs.mozilla.org?) with overview, current projects, project pages, relevant links, downloads?
| |
| * Forum/newsgroup for discussion of new project ideas, proposals, current projects, etc...
| |
| * Wiki for project lists, project pages, permanent and evolving documentation
| |
| * Private CVS/Subversion tree for collaborative development
| |
| * Bugzilla instance for project-specific bug tracking, feature requests, etc...
| |
| | |
| | |
| == Timing & Staffing ==
| |
| | |
| The intention is to launch in time with the release of Firefox 2.0 and support the innovation and platform messaging.
| |
| | |
| For staffing:
| |
| * Basil Hashem for overall process management
| |
| * Startup/corporate fractional participation
| |
| * Fractional time from Mozilla engineers, IT, Release/Build, QA, marketing, executive
| |
| * Rely on existing shared IT services for Mozilla
| |
| * Potential engineering new hires
| |
| | |
| == Oversight & MetaWork ==
| |
| | |
| * Monthly and on-demand status reports will be generated for project tracking, highlighting accomplishments and documenting learnings
| |
| * Some PR & marketing needs to be done in order to drive traffic to the new site and get momentum
| |
| | |
| == Technical Process ==
| |
| | |
| '''''Stage 1: Sourcing ideas'''''
| |
| | |
| Mozilla "Prototypes" will be completely open for sourcing of ideas. They can come from anywhere including Mozilla employees, community contributors, startups/corporates, universities, marketing partners, research labs, the extended Mozilla circle, users, etc... The ideas will be documented and categorized onto a wiki. This is a continuous process.
| |
| | |
| A project should be documented as a proposal that include a hypothesis that need to be tested, an idea that needs to be validated (or refuted), a technical feasibility, a design that need to be created, etc.... In any case, a clear yes/no or documented outcome needs to be stated for a project. Projects should not be "open ended".
| |
| | |
| '''''Stage 2: Launching and Running Projects'''''
| |
| | |
| MP will evaluate the project proposals and based on staffing and strategic interests select a handful of projects to be run simultaneously. The project proposal will be refined, staffing and duration will be set and necessary infrastructure (wiki, bugzilla, cvs, etc...) for each project will be created.
| |
| | |
| Here are some notes from mconner on guidelines for how work on Firefox might flow:
| |
| * Form a small team - 2-3 hackers, 0.5 UI guy, 0.5 visual/graphics guy, and a triage/QA helper (optional)
| |
| * Firefox-related projects will not be run on the mainline or the trunk.
| |
| * Base work on most recent Firefox release branch, use build-config magic to replace Firefox pieces with forked bits.
| |
| * High risk/high reward work that doesn't belong on the main dev path (distracting from mainline development and testing)
| |
| * New features have a shelf life, either they are good enough for n+1 or they're not. If they're not, they get dropped aggressively.
| |
| * Little to no build team resources needed (tinderbox/nightly builds, milestones are just nightlies)
| |
| * Focus on rapid iteration over clean code (we can reimplement cleanly if the idea pans out)
| |
| * Successful features get ported to the product by the mainline team at the appropriate times
| |
| | |
| For UI-focused projects:
| |
| * Build prototypes using tools
| |
| * Draw information models and user task/data flow diagrams
| |
| * Consider user testing in a focus group
| |
| | |
| | |
| '''''Stage 3: Project Evaluation'''''
| |
| | |
| At the end of a project, the evaluation will take place to determine the lessons learned and future fate of a project.
| |
| | |
| == FAQ ==
| |
| '''Q. Why not use the Mozilla Addons site?'''
| |
| | |
| A. Not everything will necessarily be an extension. Some of the projects could be delivered as special builds, separate clients, documentation, visualizations, etc... Also, Addons are typically "completed" solutions for users. MP can be a hack or a partial solution and may have much less testing done than a widely distributed extension.
| |
| | |
| '''Q. Is Mozilla "Prototypes" the real name?'''
| |
| | |
| A. No, it's a placeholder. Candidate names include:
| |
| * Mozilla Labs - labs.mozilla.org
| |
| * Mozilla Research - research.mozilla.org
| |
| * Mozilla Invent - invent.mozilla.org
| |
| * Mozilla Make - has UNIX geek cred
| |
| * Mozilla <Keyword> where keywords (to get the juices flowing): ideas, seeds, new, create, discover, find, sow, experiment, study, test, fieldwork, nest, probe, explore, check out, design, define, forge, original, generate, produce, crystal, unearth, dig, root, investigate, conceive, demo, show, prototype, protos, pros, eggs, nuggets, jewels,
| |
| | |
| Definitely open to ideas on naming. Ideally, we want something reflective of innovation as well as has a reasonable sized URL.
| |
| | |
| == Got Suggestions? ==
| |
| * Add to the discussion page
| |
| | |
| == Stuff to Investigate ==
| |
| * Collab.net - http://www.collab.net
| |
| * P&G - IDEO Relationship
| |
| | |
| == Open Questions ==
| |
| | |
| * What is the name?
| |
| | |
| == Mantras & Cautions ==
| |
| * "Ideas are nice but code and working prototypes rock!"
| |
| * "Don't show unfinished prototypes to stupid people"
| |
| * How to deal with current business feasibility constraints for an experiment?
| |
| * How to ensure that we focus on building and testing the solution rather than how to package it, clean it up and sell it to the organization
| |
| | |
| | |
| == Why ==
| |
| | |
| Need an outlet, good PR value...
| |