Platform/Features/Notifications

Feature	Status	ETA	Owner
Notifications	Needs deeper specs. Has some early prototypes.	Unknown	Christopher Blizzard

Summary

Notifications is a feature that makes it possible for web-based applications to send messages from applications to users. These messages can either be delivered as a popup bubble or can be delivered to an application as an API callback and then processed.

Different phases for this feature will add functionality over time.

Phase 1: Demo working notifications sent from a queue on a server to the browser. Display in a pop-up bubble only.

Phase 2: Define in-browser APIs for in-page delivery. Demo delivery of messages to an in-app API.

Phase 3: Define how this integrates with mobile platforms. Demo delivery of messages to an in-app API running on mobile, delivered via SMS or some other async method.

Phase 4: Define how messages can be delivered without a page being opened. Define a way to create a page or process a message without a page being open. (Think worker threads.) Demo how pages and notifications can be created on demand in response to a message.

Needs stories for developers and users.

Team

This feature requires a combination of people spread across services and applications.

• Feature Manager: TBD - project mgr in Services
• Lead Developer: TBD
• Product Manager: Christopher Blizzard
• API Review: Jonas Sicking, Doug Turner, Johnny Stenback.
• QA: TBD
• UX: TBD
• Accessibility: TBD
• Security: TBD
• Privacy: TBD

Team list should make it clear who to ask about what, and who to ping when they're needed. If you do not need someone in a particular role (ie: Security), that's fine, just delete that line. Contact info for each person would also be handy.

Release Requirements

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

Next Steps & Open Issues

Either the next set of tasks that need to happen to move this project along, or (ideally) the full list of project tasks/action items with things crossed off as they're finished. Including the name of who's responsible for each item, and a rough ETA can be useful.

Open issues include unanswered questions, things that need to be explored, decisions that still need to be made, etc. Again, including the name of who's responsible for each item can be useful.

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.

Risks

Identify, prioritize, track and communicate any risks associated with this feature/project.

Use Cases

Everyone loves use cases, so you should provide them if you can (and where it makes sense). The Channel Switcher Feature Page has some good examples.

Designs

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

Test Plans

Any and all test plans and strategies. Either inline or linked to.

Goals

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.

Other Stuff

Can include things like:

• Competitive landscape
• Research & references
• Whatever else is useful to the project.

Legend (remove if you like)

	Healthy: feature is progressing as expected.
	Blocked: feature is currently blocked.
	At Risk: feature is at risk of missing its targeted release.
ETA	Estimated date for completion of the current feature task. Overall ETA for the feature is the product release date.

Please remove this line and any non-relevant categories below. Add whatever other categories you feel are appropriate.