D7.2 Preserve editorial, Person, data and assets while adopting the shared toolkit

Aperta
#452 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
15/100
Tipo di issue
Refactoring
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend, content, data

Direzione di ricerca

No implementation files or tests are named. Start with the current DTC AGENTS/PROCESS and governing specs, then read #384 and reconcile the referenced compatibility decisions and dependencies before engineering. Done requires approved per-kind contracts, lossless corpus/rendering and asset verification, atomic failure controls, immutable package/source gates, and green development deployment.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

content enhancement integration needs grooming P1

D7.2 Preserve DTC editorial, Person, data and assets while adopting the shared toolkit

Raw intake for PM grooming; implementation not authorized. Repository: DataTalksClub/website. Plan authority: community-base phase7 D7.2, dependencies C7.12 and D7.1; current DTC AGENTS/PROCESS and specs govern site delivery. No C5.3/course-release dependency is introduced.

User intent: simplify and unify backend content parsing/rendering through the released community-base toolkit while preserving every current article/book/podcast/Person/data/asset/source/reader/history/UI behavior. No visible redesign, feature loss, source narrowing, data reset or live operation is requested.

Required full outcome

  • Article/book/podcast ingestion becomes thin toolkit adapters with site-owned SyncedDocument storage and current metadata, reader shapes, field/order/provenance/raw-source contracts. Preserve article FAQ/blocks/charts/math/YouTube and authored formatting; books links/archives/covers/Person references; complete podcasts descriptions/transcripts/timestamps/speakers/resources/player/platforms and current route/SEO/catalogue behavior.
  • Podcast descriptions follow the already normative strict nonempty scalar requirement; no intro/short/transcript/generated fallback. Current permissive parser is characterized and corrected with lossless valid-corpus equality and malformed-input atomic rejection, not a new editorial policy.
  • Package Person/parser becomes sole storage/parser only through a released compatible legacy-source contract and reviewed atomic reader cutover. Preserve exact short identity and public profiles/links/portraits/ordered author/book-author/guest/Event credits and recording-lineage dedup; no People hub, fuzzy/account joins, dual storage/fallback or premature D7.4 source move.
  • FAQ keeps its current format as a site kind; podwiki graph/search remain opaque data from their current producer. Platform/Slack data adoption preserves functional validators, singleton IDs/fields/order/source/provenance/cleanup/operator reports and public buttons/page, not merely YAML decoding.
  • Referenced assets apply to approved converted input. Every currently served legacy external path retains exact reviewed bytes until a separately accepted compatibility cutover; unreferenced assets are not automatically deleted. Synced editorial rendering retires duplicate cleaner calls only after exact caller ownership changes.

Existing ownership and decisions to reconcile

Reuse #384 for already-landed engine/readers and pending staged/storage/docs-asset retirement; do not repeat its work. Reconcile #40's exact-short foundation with later D23/D24/database-only authority and link the separate Person storage/reader compatibility work. #105 accepted development is not reopened; its remaining HUMAN gate belongs to #74.

Before engineering, PM binds the exact immutable package release/API, configured source/converted manifest and corpus/render/asset provenance, current path ACKs, and cohesive per-kind contracts. Recorded#384 route ruling versus stale spec02/03 route prose needs an exact current compatibility/spec reconciliation; preserve current behavior without silently restoring aliases or creating another break. Person legacy compatibility, data publisher ownership and selected source support must be proved, not assumed from a tag.

Proposed serialized parts: article adapter first; book/podcast adapters; FAQ/graph/search/platform/Slack data contracts; released package-Person compatibility + site reader/storage migration; asset compatibility. Split according to repository process/actual owners; parent closure requires the entire D7.2 outcome, not the first part. No duplicate render/validation/generator/store framework.

Evidence and completion boundary

Require same-source nonempty corpus equality, accepted55-article human-reviewed rendering diff, exact fields/transcript/Person reference and asset path/byte inventories, deterministic replay/cache/provenance and atomic failed-source/cleanup controls. Fresh DTC verification plan, independent Tester terminal evidence/screenshots when graph-required and PM acceptance precede focused commits. Immutable package pin/lock/source gates and actual green development deployment remain mandatory. #442 infrastructure owner resolves deployment; historical reports are references, not borrowed current proof.

Production/cloud/credentials, source authoring/moves, data reset/import/deletion, deployment and cutover are not authorized by intake. Every existing UI/route/task/data/history feature remains until its accepted replacement and required owner receipts. Existing foreign source ownership is preserved. This raw intake grants no source ownership or STATUS change.

Lingua principale
Python
Stelle
0
Fork
0
Merge medio
1m
PR unite (30g)
2

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DataTalksClub/website

Tutte le issue di DataTalksClub/website

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.