User:Mconnor/Past/Services Beta Channel

Overview

In order to move faster and prove out new ideas, we will create an environment for both beta features and experimental ideas, consisting of both new client features as well as new server-side offerings. This will be a superset of our current production offerings, with no overlap between the environments. Users will need to explicitly create accounts with revised Terms of Service to join the early access program. We will ship an add-on which makes this action easier for existing users, but the requirement for isolation is to allow us more freedom to deploy new services quicker, and opt into even earlier access to experimental services.

Server Environment

This will be a new set of infrastructure, starting with a deployment of all of the current Services apps (excluding KeyEx, which is account-agnostic). We will treat this as an explicit opt-in sandbox, with a fully separate set of accounts, user data, and servers. It will be isolated from the production environment, and carry different Terms of Service, Privacy Policy, and SLA requirements.

Experimental services will require an explicit user opt-in before use. Whether this is a single opt-in, or a per-experiment opt-in, will be determined by the product driver for those releases.

Client Feature Channels

The Mozilla Services beta channel will use the same architecture as LabKit to create a client feature beta channel independent of the Firefox beta channel. This means that we will build new features as restartless add-ons first, and roll them out to users of the beta channel. Users of this channel will need to have an account on our beta infrastructure to make use of any client features dependent on new services or service features.

The Mozilla Labs experimental channel user experience is still TBD, but is expected to require a more explicit opt-in.

Beta Channel Process

This is a channel for bridging from prototype to product. As such, we will establish criteria for entry and exit, with an active update and feedback process in between.

Entry Criteria

• The core concept has been prototyped and evolved to the point where we think it's a compelling enough feature/service to start accelerating
• If there is a user data component, we've gone through the initial iteration/refinement/assessment phases and have preliminary sign-offs
• There is a clear Product desire to move the feature towards Firefox inclusion
• We have defined UX and Product requirements for a beta-quality feature, and we've built that

Development Process

• New revisions will roll out weekly on a defined cycle, with QA/UX/infrasec signoffs
• We will use input.mozilla.com as our primary feedback channel to guide next steps
• All active projects will be reviewed monthly by Product/Engineering/UX
  • Projects that fail to meet exit criteria will be iterated or killed aggressively

Exit Criteria

• Product
  • All necessary UX signoffs for product pieces and web-facing aspects
  • Product Manager signs off that current product meets requirements/goals
  • We have reached some threshold for user feedback and adoption that justify increasing investment
• If there is a user data component, we've finished the reviews/sign-off portion of the user data process.

Initial Requirements

Infrastructure

• Capacity for 100k-500k users will be deployed, with full metrics support
• This environment will not be able to share account information or data with production services.
• Initial signoffs will still be required from Security/Privacy/Product before deploying to this environment. These signoffs will apply a looser standard than for production-level signoffs.
• There will be two SLA levels, one for "beta" services and one for "experimental" services.

Legal

• New ToS/PP will be required
  • Must be open-ended enough to include future products
  • No guarantees around user data/encryption
  • Part of the work on this channel will involve deeper analysis and tracking of usage. Part of the tradeoff for getting cool new stuff, bigger quotas, etc is that we will track users more closely to help guide product decisions.
  • There will be an additional opt-in agreement for experimental options, including opting in to heavy instrumentation of features and disclosure of some amount of PID (TBD)

Product

• Need to define branding for this channel
• Need to define sufficient uptake to move to production

Engineering

• We will need to develop the client add-on and get that channel ready for use.
  • Ideally this will modify the existing account sign-up process to make it trivial to move to the beta channel.

Next Steps

Phase 1

• Services Ops is already building out initial infrastructure bug 659787 (jvier already running with this)
• Need to engage PMM to figure out branding questions (mconnor + mayumi)
• Need to engage Legal on new ToS/PP requirements (mconnor)
• Need to build and test "Beta" Client add-on (mconnor on point to find resources)

Target is to be able to launch in early July. The initial service deployed to Beta is expected to be Identity.

Phase 2

• Support for experimental features in account portal
• Experiment client channel up and running