Service Context & Docs

[lexicondevil]

Note: This is issue is part of the Service Transfer Project. The goal is to ensure project documentation is up to date and help the receiving team understand what the service does and how to maintain and operate it. The previous team is primarily responsible for doing this work, and the receiving team is the stakeholder on this issue and has final approval.

These are a set of guidelines, not a rigid set of requirements. If the receiving team already has expertise on this service and is comfortable operating it, they may complete whatever subset of the tasks they find appropriate and close this issue.

The assignees on this issue are intended to be "manager of previous team" and "manager of new team" based on what's in the Service Ownership Spreadsheet. If these are incorrect please update the assignees on this issue and update the spreadsheet to match.

Service Context

Please provide links to any service or project documentation, so the receiving team can understand its purpose and how it fits into the rest of the system.

Recommended:

• Project RFC
  • What problem are we trying to solve
  • Documented success criteria
• Description of service capabilities - What are the distinct pieces of user-facing functionality that this service provides or enables? Describe or link to document.
• Architectural documents
  • Service diagram - Show all internal & external dependencies
  • Schema / data model / dataflow diagram

Nice to haves:

If you have any of these project-related docs please link them.

• Cost models (new services)
• Projected user growth
• Anticipated load/demand/users modeled
• Project Dependency Mapping

[rybit]

This is an public repo. I'm going to close this for now.