Skip to main content

Documentation Ownership

This page defines where documentation should live and how it should be maintained.

Core rule​

Use intt-docs as the central documentation hub for anything that spans more than one repository.

What belongs in intt-docs​

  • onboarding
  • system architecture
  • service map
  • deployment and release process
  • troubleshooting used by multiple teams
  • glossary and business flow summaries

What can stay in service repositories​

  • low-level implementation notes
  • module-specific API details
  • service-local scripts and setup notes
  • repository-specific developer conventions

Writing rule​

When a change affects:

  • more than one repository
  • local setup steps
  • architecture understanding
  • release flow
  • onboarding guidance

update intt-docs.

When a change only affects one service internally, update that repository README or internal docs and add a link from intt-docs if the change matters to wider teams.

Ownership suggestion​

  • each service owner maintains service-specific pages
  • tech lead or platform owner maintains onboarding and architecture pages
  • every feature PR should check whether docs need an update

Review checklist​

Before merging a change, ask:

  • does setup change
  • does architecture understanding change
  • does service ownership change
  • does release or troubleshooting guidance change

If yes, update docs in the same change set.