Decide separate repository strategy for operations documents

[alexeygrigorev]

Goal

Decide and implement the repository boundary for DataOps operational documents.

The current v1 merge keeps app code and imported content/ in DataTalksClub/dataops. We likely want operational documents in a separate GitHub repository so they can be edited, reviewed, permissioned, and synchronized independently from portal code.

Questions To Decide

• Should the docs repo be public or private?
• Should the docs repo contain only content/, or also document templates, screenshots/images, process metadata, and podcast knowledge documents?
• What should the repo be named? Candidate: DataTalksClub/dataops-docs.
• Should the portal read docs directly from the docs repo at runtime, or should CI mirror docs into the app artifact?
• How should edits from the portal commit back to the docs repo?
• Should issues for document work live in dataops, the docs repo, or both with cross-links?
• What branch and review rules should apply to docs edits?

Candidate Direction

• Keep DataTalksClub/dataops for application code, task engine integration, assistants, infra templates, CI/CD, and product planning.
• Create a separate docs/content repo for operational documents and assets.
• Configure the Lambda app with GITHUB_OWNER, GITHUB_REPO, and GITHUB_BRANCH pointing to the docs repo for content reads/writes.
• Keep portal deploys code-driven, and make docs repo pushes trigger a cache refresh and content validation workflow.

Acceptance Criteria

• ADR documents the repo boundary and chosen repo name.
• Migration plan lists files/directories to move from dataops to the docs repo.
• Runtime configuration changes are identified for Lambda content reads and portal edits.
• CI plan covers docs validation and deployed cache refresh from the docs repo.
• Permission model is documented for app deployers vs document editors.

[alexeygrigorev]

Additional requirement: DataTasks templates should be considered part of the process/document repository boundary.

Rationale:

• Templates encode the repeatable operational process, not just app runtime seed data.
• If the app/runtime database is lost or rebuilt, templates should remain preserved in Git.
• Template changes should be reviewable like process document changes.
• The docs/process repo layout should decide where templates live alongside SOPs, playbooks, podcast workflows, and related metadata.

Layout options to evaluate in the ADR:

• content/ for human-readable docs and templates/ for machine-readable task templates.
• processes/<domain>/docs plus processes/<domain>/templates for colocating each workflow family.
• Keep templates as YAML/JSON with generated views in the portal.
• Maintain a migration path from current DataTasks seed templates into Git-backed canonical templates.

Acceptance criteria addition:

• ADR explicitly decides the canonical Git location and format for DataTasks templates.
• The implementation plan includes loading/syncing task templates from Git and preserving them independently of any runtime datastore.