D7.2 Preserve editorial, Person, data and assets while adopting the shared toolkit
还没有人认领这个 Issue。
评估
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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.
- 主要语言
- Python
- 星标
- 0
- 派生
- 0
- 平均合并
- 1 分钟
- 30 天内合并 PR
- 2
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
DataTalksClub/website 的其他 Issue
-
bug infra operations P1 testing
难度 2/5 1-3 小时 新手友好度 72/100
DataTalksClub/website#329 ·
-
bug content data-migration documentation events operations P1
难度 2/5 1-3 小时 新手友好度 84/100
DataTalksClub/website#327 ·
-
bug frontend P0 testing
难度 2/5 1-3 小时 新手友好度 90/100
DataTalksClub/website#300 · 7 条评论 ·
-
bug data-migration events P0 testing
难度 2/5 1-3 小时 新手友好度 72/100
DataTalksClub/website#295 · 6 条评论 ·
-
bug infra operations P1
难度 4/5 1-2 天 新手友好度 25/100
DataTalksClub/website#474 · 4 条评论 ·
查看 DataTalksClub/website 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 64/100
its-me-prash/vwgroup-connect-ha#2019 ·
维护者通常 1 天内回复
-
bug good first issue
难度 2/5 1-3 小时 新手友好度 86/100
KonstantinStarovoytov/kitden#21 ·
维护者通常 1 天内回复
-
Refactor未关闭
难度 2/5 1-3 小时 新手友好度 62/100
ehmatthes/gh-profiler#166 ·
-
难度 2/5 1-3 小时 新手友好度 68/100
smart-on-fhir/smart-fetch#73 ·
-
good first issue help wanted
难度 1/5 1-3 小时 新手友好度 85/100
RizgarOzan/playcal#13 ·