User:Mconnor/Past/UpliftNotes

All Labs projects have regular checkpoints to review progress, assess continued investment, and identify new areas of exploration as initial goals are reached. As part of this process, we will identify high value feature or behaviour changes that we should consider for uplift into one or more products (Firefox, Fennec, etc).

To be clear, inclusion as-is in a product is not expected to be a typical end state for Labs projects. In most cases so far, there is a desire to further explore the problem space, and while we will be working to include parts of projects, or features based upon lessons learned, those projects will continue to exist and explore more aspects of the problem beyond what we may initially include in the product.

Once we have identified a project that we believe is interesting enough to be the basis for a core product feature, the next step is to identify specifics. This includes what aspects are desired from a product perspective, what we do and don't have already in terms of UI and technology/services, what risk factors are involved, and more. To act as a basis for decision-making, we have [created a template] for answering the important questions required to properly assess, plan and execute the project.

Some existing examples are already complete for the first iteration on core features based on [Prism] and [Persons]. The idea is to call out everything, including non-goals, to leave as little ambiguity around intent and intended outcomes as possible. From this single document, we can determine required resources, build a roadmap, and file the required bugs for all of the component pieces that must be in place for the project to succeed.

Once we have a project plan, the plan is to work on implementation in a separate repository from mozilla-central, and checkpoint frequently. Merging to the mainline will not happen until the project has completed product design and security reviews. Again, to be clear, greenlighting an uplift project does not guarantee that we will ever ship the result of that project. If we decide that the end result is not compelling enough, like all Labs projects we will either change the project or end work.

Future needs:

Need to architect experiment code in such a way that it is not a matter of completely reimplementing work in order to include some or all of it within the product. Should be possible to do this.