Labs/Cherrypicker
Status
| Cherrypicker | |
| Stage | Draft |
| Status | ` |
| Release target | ` |
| Health | At risk |
| Status note | Need to do design validation before we invest too much time. |
Team
| Product manager | Bryan Clark |
| Directly Responsible Individual | ` |
| Lead engineer | Simon Wex |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | Andy Chung, David Ascher |
Open issues/risks
- Design Validation: does the idea have legs?
- Delivery: is this something we'd want to offer at scale?
- Security
- Compliance
- Long-term commitment
Stage 1: Definition
1. Feature overview
Cherrypicker is a codename for a service which we're exploring. This service is an email service which users would use to sign up for webapps, especially those they don't trust yet. Using a cherrypicker email account has the following values for users:
- I don't need to share my (valuable) primary email address with a web app until I trust it
- Web apps tend to send me bacn (machine-generated mail) which clutters my inbox, but is hard to find when I need it. Cherrypicker manages those messages intelligently, so that they're available when I want them, but out of my way most of the time. Examples include:
- friend requests
- shipment notifications
- periodic announcements
- If a webapp turns out to be spammy, I can delete it from cherrypicker, and the service unsubscribe me from the app, and hide those messages from me whether the app honors the unsubscription request or not.
For webapps, cherrypicker can be an on-ramp to a higher-fidelity notification system with users: cherrypicker can both advertise and support direct messaging to the user through a (not-yet-designed) notification protocol, so that as an app developer, I can reach my users without having to fight spam detection, write lowest-common denominator email HTML, and unpredictable delivery delays.
2. Users & use cases
Someone who wants to try a webapp but is uncomfortable sharing their primary email address, or for whom the expected impact of possibly getting junk/spam/bacn is a deterrent to exploring the web.
Someone who is an eager user of webapps, but who'se drowning in an overflowing inbox and wants help sorting the wheat from the chaff.
3. Dependencies
- Likely we'll use the verified email protocol to make signup easy.
- Downstream, there are possible Firefox integration scenarios where Firefox, if it were to detect signups to a webapp, could offer the cherrypicker account, or even generate pseudonymous (per-site) accounts.
4. Requirements
`
Non-goals
This is not about making a generic webmail. The set of messages we'd want to capture are explicitly computer-generated notices.
Stage 2: Design
5. Functional specification
`
6. User experience design
`
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
`
Feature details
| Priority | Unprioritized |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | ` |
| Secondary roadmap | ` |
| Feature list | ` |
| Project | ` |
| Engineering team | ` |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
Cherrypicker is an exploration by Mozilla Labs of a possible service to provide better communications between webapps and people.
Current stage: level 0 -- design phase.
Project artifacts
Coordination
- Weekly meetings: Mondays 2pm, vidyo, "david ascher" room? (we'll try)
- Google group
Minutes
- Meeting 0, June 20, 2011: agreeing to project definition, meeting simon
