ChannelSwitching/ChannelSwitchingFeature

Feature	Status	ETA	Owner
Means by which users on our new Experimental, Beta and Final channels can switch the channel they are on.	Backend work almost complete - waiting on review. UI Design finished but need to implement.	2011-04-18	Sheila Mooney

Summary

In order to support our new shorter release cycle, we need a mechanism by which users can switch what channel they are to get on that update path. This applies to users who are on the experimental (new), beta and final channels.

The nightly channel is a separate path and they will continue to receive the nightly updates for mozilla-central. In order for those users to get on a different channel ie: beta, they must first download a beta build.

Implementation includes some back end work as well as minimal front-end UI for doing the switching.

Release Requirements

Complete checklist of items that need to be satisfied before we can call this feature "done".

Next Steps

A team is tracking this work during weekly meetings on Wed @10:00am.

Most of the backend implementation is complete. The UI design work is done and we are waiting on the front-end development.

Related Bugs & Dependencies

Links to the feature tracking bug & other relevant bugs; links to related plans (test plan, product marketing plan, etc.); notes about things that depend on this, etc.

Team

Should start with a short intro explaining that this is the current set of team leads, but anyone is welcome to dive in and help out.

Team list should make it clear who to ask about what, and who to ping when they're needed. Not all team members will be actively involved with the project at all times, but we should have an idea of who will be the touchpoint for each involved group (PM, marketing, devs, UX, graphic design, services, webdev, QA, etc etc)

Team info should include notes about where they hang out in IRC, if there's a mailing list, etc.

Designs

Any and all mockups, design specs, tech specs, etc. Either inline or linked to.

Goals/Use Cases

The high level goals for the feature (which the release requirements checklist should fulfill). These are the guiding light and overall vision for the feature. Refer to this if there is confusion or are disputes about direction, designs, planning, etc.

Non-Goals

Things we are specifically not doing or building as part of this feature.