Status
| Contacts Mediator | |
| Stage | Draft |
| Status | In progress |
| Release target | ` |
| Health | OK |
| Status note | ` |
{{#set:Feature name=Contacts Mediator
|Feature stage=Draft |Feature status=In progress |Feature version=` |Feature health=OK |Feature status note=` }}
Team
| Product manager | ` |
| Directly Responsible Individual | ` |
| Lead engineer | ` |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
{{#set:Feature product manager=`
|Feature feature manager=` |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
Open issues/risks
- Do we provide our own contacts server?
- How is caching/offline access handled?
- How does it interact with the Profile Mediator and Profile Servers? Does this point to other users' Profile Servers? Or do they just return similar data types (jcard vs list of jcards)?
Stage 1: Definition
1. Feature overview
It's helpful to be able to have a central repository for all of your contacts across your networks. This centralized access point also allows for easier definition of relationships and access control.
From this repository, sites can request access to a user's social graph to increase the site's features' social relevancy, and the user can limit the scope of social graph which said site can access. As with all OWA Mediators, it allows for user selection of which services they wish to provide data to interested parties, be it Google Contacts, their Facebook graph, or a local Address Book.
This feature will provide such an access point. Through interaction with a user's activity streams manager (Delta), the Contact Manager will also be able to know which of a user's contacts are already on sites which are requesting access to the graph, and only let the site know the relevant pieces of their social graph.
2. Users & use cases
- Provide a centralized access point for a user's contacts across various sites
- Empower users to control sites' knowledge of their social graph
- Through increased control, sites will gain increased user trust, and this in turn will promote social activity to permeate apps and the web
3. Dependencies
- Revive the old Contacts add-on
- Merge with F1's current contacts backend
- Delta (for scoping return values)
4. Requirements
- Define API
- Storage server
- Support for friend, follow, and private profile follow models
Non-goals
`
Stage 2: Design
5. Functional specification
`
6. User experience design
The site-based prefs will be implemented in content at an about page (about:contacts). It will be in-content (much like [about:addons]), and is intended to build off of the mechanisms of the Site-based data management UI as appropriate.
Stage 3: Planning
7. Implementation plan
- Salvage old Contacts Addon for API
- Build mediator
- Salvage old Contacts Addon for caching/offline access
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
` {{#set:Feature open issues and risks=* Do we provide our own contacts server?
- How is caching/offline access handled?
- How does it interact with the Profile Mediator and Profile Servers? Does this point to other users' Profile Servers? Or do they just return similar data types (jcard vs list of jcards)?
|Feature overview=It's helpful to be able to have a central repository for all of your contacts across your networks. This centralized access point also allows for easier definition of relationships and access control.
From this repository, sites can request access to a user's social graph to increase the site's features' social relevancy, and the user can limit the scope of social graph which said site can access. As with all OWA Mediators, it allows for user selection of which services they wish to provide data to interested parties, be it Google Contacts, their Facebook graph, or a local Address Book.
This feature will provide such an access point. Through interaction with a user's activity streams manager (Delta), the Contact Manager will also be able to know which of a user's contacts are already on sites which are requesting access to the graph, and only let the site know the relevant pieces of their social graph. |Feature users and use cases=* Provide a centralized access point for a user's contacts across various sites
- Empower users to control sites' knowledge of their social graph
- Through increased control, sites will gain increased user trust, and this in turn will promote social activity to permeate apps and the web
|Feature dependencies=* Revive the old Contacts add-on
- Merge with F1's current contacts backend
- Delta (for scoping return values)
|Feature requirements=* Define API
- Storage server
- Support for friend, follow, and private profile follow models
|Feature non-goals=` |Feature functional spec=` |Feature ux design=* A site requesting limited contacts
The site-based prefs will be implemented in content at an about page (about:contacts). It will be in-content (much like [about:addons]), and is intended to build off of the mechanisms of the Site-based data management UI as appropriate.
|Feature implementation plan=* Salvage old Contacts Addon for API
- Build mediator
- Salvage old Contacts Addon for caching/offline access
|Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}
Feature details
| Priority | Unprioritized |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | ` |
| Secondary roadmap | ` |
| Feature list | ` |
| Project | ` |
| Engineering team | ` |
{{#set:Feature priority=Unprioritized
|Feature rank=999 |Feature theme=` |Feature roadmap=` |Feature secondary roadmap=` |Feature list=` |Feature project=` |Feature engineering team=` }}
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}