DataTalksClub / DataTalksClub/website
Epic: Adopt the course platform and evolve Course into Course → Cohort
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Normative authority:
- 04 — Course-platform adoption and Course → Cohort
- 09 — Migration, rollout, and roadmap
- 10 — Verification strategy
- course-platform adoption provenance
Outcome
Adopt the existing course-management platform without silently losing its business behavior, then perform an expand-and-contract evolution from edition-like Course records to reusable Course parents with Cohort deliveries.
Boundaries
This is not a rewrite and it is not an automatic mirror of CMP main. Proven enrollment, submission, peer review, scoring, leaderboard, complaints, certificates, calendars, dashboards, compatibility APIs, and operational workflows remain characterized while architecture and authorization are changed deliberately through their owning issues.
The website remains bound to the immutable CMP pin in _docs/adoption/course-platform/source-pin.json. Later CMP commits are reviewed as discrete packets. A packet is selectively adapted, deferred, or rejected through an explicit issue; no upstream commit, migration, API, email behavior, or source-pin movement is inferred from its existence.
Epic completion gate
- The literal-copy adoption baseline and its copied characterization suite are accepted: #13 and #30 are closed, with immutable source/overlay provenance and recorded green on-call evidence.
- The three original product decisions are resolved: #14 fixes cohort-owned curriculum and definition-only duplication, #15 fixes explicit reviewed legacy-edition mapping with no live regex inference, and #16 fixes canonical
/courses/<course>/<cohort>/paths plus the owner-approved legacy-host redirect posture. - The reviewed historical mapping and repository expand path are accepted and integrated through #224 and #51, with stable legacy identities, fail-closed mapping consumption, replay/rollback evidence, and no learner/submission loss.
- Every preserved course workflow is either delivered through #52–#59 and the exact accepted #54 child interfaces, or explicitly retired/deferred by its owning product decision. Source-only code, a frozen candidate, or a closed parent decision is not completion evidence.
- Studio and
/api/v1/admin/parity has a no-gap #30-derived operation matrix, shared service/capability enforcement, compatibility ownership/removal gates, and accepted #59 evidence. - #60 passes the separately authorized production-like full import/reconciliation, compatibility, backup/restore, freeze/delta, and application-rollback rehearsal with every outbound website/Relay/Datamailer path disabled.
- The accepted #60 legacy-host map is consumed by #71; its inactive source/rehearsal and later #74 production activation/rollback observation satisfy #71's HUMAN close gate. The permanent
@courses.datatalks.clubcalendar UID namespace is unchanged. - Every post-pin CMP packet is classified. Every adopted packet has its own engineer → independent tester → PM → focused commit → local no-ff merge/push → exact-SHA on-call-green lifecycle; every deferred/rejected packet has an explicit owner disposition and exclusion boundary.
Accepted baseline and decisions
- #1 — runnable Django/uv foundation
- #13 — adopt CMP rather than rewrite it
- #14 — cohort-owned curriculum decision
- #15 — explicit legacy edition/family mapping decision
- #16 — canonical course URL and legacy-host decision
- #30 — literal-copy adoption and characterization baseline
- #35 — compatibility/redirect/link/SEO parity-gate foundation
Core delivery children
These remain separate lifecycle issues; an open issue is not satisfied by already-present source or another issue's evidence.
- #51 — Course → Cohort structural migration; blocked on accepted/integrated #224
- #52 — scoped course capabilities and API principals; blocked on its exact identity/authorization inputs including #51
- #53 — lifecycle, canonical/public compatibility routes, and complete duplication; blocked on accepted #40, #51, and #52
- #54 — registration, enrollment, and learner-flow coordination epic; its exact child outcomes must be delivered or explicitly dispositioned
- #55 — homework/submission/scoring preservation; blocked on #51, #52, and #53
- #56 — project/peer-review/voting/scoring preservation; blocked on #51, #52, #53, and accepted #230
- #57 — score/leaderboard/privacy/complaint preservation; blocked on #52, #53, #244, #55, and #56
- #58 — graduates/certificates/Wrapped preservation; blocked on #52, #53, #244, #245, and #57
- #59 — final Studio/admin API completeness and parity integration; blocked on its accepted authorization, domain, registration/enrollment, and send-disabled management interfaces
- #60 — production-like full migration and compatibility rehearsal; downstream of all exact accepted course-domain and #54 child interfaces named in that issue
- #71 — inactive legacy-host redirect source/rehearsal followed by the separate HUMAN activation gate; blocked on accepted #60 map evidence
Historical mapping, account/profile, and learner-flow join
#224 -> #51
(#224 + #51 + #231 + #234) -> #247 -> #248
#247 -> #242
(#242 + #248 + accepted ordinary-delivery interface from #49) -> #243
(#230 + #242 + #248) -> #244 characterization
accepted #243 conversion interface -> #244 final acceptance
(#243 + #244 + #32 + #33 + #52 + owner-approved #288) -> #245 -> #246
#224 supplies the reviewed pre-2024 mapping, removal of live regex inference, certificate-source coverage, and durable legacy identifier. #51 consumes it for repository structure and synthetic populated-data proof. #60—not #224 or #51—owns the later authorized production-like/full historical import and reconciliation.
#231 and #234 do not block #51. They join accepted #224/#51 at #247, which supplies the accounts-owned MemberProfile/confirmed-scalar foundation; #248 supplies the verified onboarding and compatibility-projection cutover consumed by registration and learner flows. Parent #54 is coordination, not an implementation interface and not a closable prerequisite of #60.
CMP transition-window ledger
Fresh read-only audit on 2026-08-30 found CMP main unchanged at 8a4d05221051748e3d95bf446c0d1cfa46dc111a; the website pin remains 98a235283904b4ef9ad29e196298540756cf1bcc. No unclassified new commit was found.
- #149 — unresolved owner decision for four substantive packets: system evaluation, peer-task visibility, score readiness/hiding, and processing/notification semantics. All four remain fail-closed; no source copy, migration transplant, overlay rewrite, child implementation, or pin movement is authorized.
- #229 — bounded persisted-submission status fix is merged/pushed as
5d660eb, but the issue remains open until its exact post-push/on-call gate is recorded. It does not by itself accept #56. - #230 — invalid peer-review-link selective adaptation; groomed, stale candidate held for reconstruction on a clean green base; later consumed by #56/#244/#60.
- #231 — exact country inventory and malformed-email characterization; groomed for fresh reconstruction and later consumed by #247.
- #232 is the unrelated homepage release-gate issue. It is an operational base-recovery concern, not a CMP packet or product dependency of this epic.
- #233 — request-time certificate notification fanout removal; valid but still
needs groomingand hard-blocked on accepted #49 durable delivery interface. It must not copy CMP's synchronous Datamailer endpoint. - #234 — normalized/collision-safe certificate lookup adaptation; groomed for fresh reconstruction and later consumed by #247. It does not absorb #233 email delivery.
- #235 — rejected/not planned. CMP bulk registration/correction APIs are excluded; target-native management remains owned by #54.
#230, #231, and #234 may be prepared independently from one clean green base, but their shared adoption-ledger edits require ordered integration #230 -> #231 -> #234, fresh fingerprints/evidence after each prior merge, and three separate closure commits. #232's recovery does not waive or satisfy any of those product lifecycles.
Delivery DAG
accepted baselines/decisions
|
+-> #224 -> #51 -> #52 -> #53 -> #55/#56
| | |
| +----------+-> #57 -> #58
|
+-> #230 ---------------------> #56 and #244
+-> #231 --+
+-> #234 --+-> #247 -> #248 -> #54 child join (#242-#246)
accepted authorization/domain/#54 child interfaces -> #59
accepted compatibility/domain/management state -----> #60
#60 map -> #71 inactive source/rehearsal -> #73/#74 activation path -> #71 HUMAN close
This diagram is a coordination summary, not permission to bypass the exact additional dependencies written in each child (including #32/#33/#40/#48/#49/#288). Any dependency-base, migration graph, source provenance, adoption ledger, capability/OpenAPI, route-map, or verification-plan change invalidates downstream candidate evidence and requires a fresh issue-owned gate.
Non-goals
- No source-pin movement, automatic CMP sync, production/protected-data access, provider action, redirect/DNS activation, sender enablement, destructive contraction, commit, merge, push, or deployment is authorized by this epic ledger.
- Do not treat existing Course/Cohort source, a stale worktree, checked issue prose, a partial suite, or another issue's acceptance as proof that an open child is complete.
- Deferred reusable/versioned curriculum remains outside this epic's required first-consolidation outcome unless an owner explicitly changes that decision through its own issue/spec update.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with specs 04, 09, and 10, then review _docs/adoption/course-platform/source-pin.json and the adoption provenance directory. Use the delivery DAG and linked child issues to identify an owned implementation rather than treating this epic as a standalone task. Done requires all listed child gates, migration evidence, preserved workflows, and rollout/rehearsal acceptance.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api, backend, database, devops
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 15/100