User:Mconnor/Past/Services Beta Channel: Difference between revisions

no edit summary
No edit summary
Line 1: Line 1:
== Overview ==
== Overview ==


In order to move faster and prove out new ideas, we will create a beta channel for Mozilla Services, 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 beta program.
In order to move faster and prove out new ideas, we will create a beta channel for Mozilla Services, 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 beta program.  We will ship an add-on which makes this transition easier for existing users, but the requirement for isolation is to allow us more freedom to deploy new services.


== Server Environment ==
== Server Environment ==
Line 10: Line 10:


Mozilla Services 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.
Mozilla Services 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.
== 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 prelim 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.


== Requirements ==
== Requirements ==
 
=== Infrastructure ===
* Capacity: In order for the userbase to be large enough to get viable feedback before making greater investment, we will aim for 100k-500k users on this channel
* Capacity for 100k-500k users will be deployed, with full metrics support
* Isolated environment: new services deployed in this environment will not be able to share account information or data with production services.
* This environment will not be able to share account information or data with production services.
* Signoffs are still required: even though this is a beta channel, we are still attaching our brand.  Security, Privacy and technical reviews/signoffs will be required before deploying a new service or client feature to the beta channel.  These signoffs will apply a looser standard than for production-level signoffs.
* 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.
* Not a prototype channel: This channel is for getting wider feedback on beta-quality features and servicesOnce UX and Product is satisfied that an idea is  refined enough to be worth building out, we will target the beta channel.
=== Legal ===
* Exit criteria: Once a feature has been deployed to beta, adoption and usage of features, along with user feedback, will be a key factor in deciding which new services/features move to a production footing.
* New ToS/PP
* Legal: We will need to define different Terms of Service and Privacy Policy, as future work may include unencrypted user data.
** Must be open-ended enough to allow for future productsNo guarantees of encryption/data protection should be made here.
=== Product ===
* Need to define branding for this channel
* Need to define "beta-quality" more concretely
* 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
Confirmed users, Bureaucrats and Sysops emeriti
812

edits