Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Integrated course-launch system: compose and send/schedule email + Telegram announcements, templates on course create, cohort schedules linked to module/project START times

未关闭
#467 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
django, python

调研方向

Start with the authoritative course, email, and admin API specs named in the issue, then inspect the existing Course/Cohort and curriculum placement models, Relay delivery boundary, capability registry, and deploy/cli.py. Map those contracts before tracing where nullable starts and migrations belong. Done means the listed API, Studio, CLI, schedule, safety, and verification criteria pass; this is a broad, multi-system project best suited to an experienced contributor.

由索引模型根据 Issue 内容生成。

描述

admin courses data-migration email enhancement integration operations P1

Integrated course-launch system (website)

Raw reporter intent preserved: compose and explicitly send/schedule email + Telegram announcements; choose announcement templates on course create; launching COHORT (never self-paced) auto-generates durable schedules linked to module/project START times with missing-starts migration + documented backfill; everything editable via API/CLI incl templates/assignments/announcements/schedules/starts (inspect CLI, add AISL/DataOps-style auth CLI if absent); no public or real-user sends during development.

Groomed spec (PM, 2026-10-17 — replaces raw intake above)

Normative links
  • Playbooks (source of announcement content + timing intent):
    • playbooks/02-course-launch-social-system.md — phased campaign (T-relative dates, module/project announcements, channel adaptation incl Slack/Telegram operational reminders)
    • playbooks/01-course-platform-setup.md — Monday 23:00 UTC deadlines, course create → campaign → outline, copy-previous-cohort schedule
    • playbooks/01-launch-checklist.md, 00-cohort-brief.md, course.yaml + copy-bank/email/, copy-bank/telegram/ (module-email-template, module-announcement-template, welcome/certificate/project emails)
  • Website specs (authoritative):
    • _docs/specs/04-courses-and-cohorts.md — Course→Cohort, delivery_mode live/self_paced, curriculum_format, cohort-owned assessment, Studio coverage, Relay-backed communications
    • _docs/specs/05-events-registration-email.md — Relay-only sends, durable EmailDelivery + leased job, preference enforcement, dev sender courses
    • _docs/specs/06-studio-and-admin-api.md — Studio + /api/v1/admin/ parity via capability registry, Bearer scoped/expiring principals, idempotency + If-Match, audit
    • _docs/specs/open-decisions.md §10/§11 (Relay), §19 (Slack join-URL secrecy — Telegram destination config must follow same no-secret-retention pattern)
  • Ownership contracts (coordinator-confirmed):
    • C-LAUNCH-1: website canonical for current cohort/module/project scheduling; website engineer owns native start fields/migrations. CMP worker adds live legacy Homework/Project starts_at + API/CLI and start preservation at import boundaries. No new cross-service scheduler.
    • DataOps process templates use existing offset_days with one Card per START anchor (separate DataOps worker — not this issue).
Scope (website repo only)
  1. Announcement templates: CRUD + versioned immutable publish; assign defaults on Course create (email + Telegram per module/project/course-event kind); per-Cohort override. Seed from playbook copy-bank with {{ }} placeholders (module_number/title/urls, homework links/deadlines, course_platform_url); placeholders render only from typed Relay context.
  2. Announcements: compose from template + cohort context; explicit two-step operator action — draft → approved/scheduled → send. Generated schedules are created unarmed (require explicit approve/schedule); edits invalidate prior approval.
  3. Cohort launch schedules: launching a COHORT with delivery_mode=live auto-generates durable schedule rows anchored to module/project START times (cohort placement-owned starts; shared curriculum never stores starts). self_paced and github_archive never generate schedules or announcements.
  4. Native starts: add offset-aware starts_at to cohort-owned timing owners (Cohort + Module placement / shared-module placement + Project; coordinator/launch-starts thread to confirm exact set incl whether Cohort/Homework course-level starts are in scope). Null-preserving; naive datetimes rejected; start <= end/deadline; explicit start edits never mutate deadlines.
  5. Missing-starts migration + backfill doc: migration adds nullable starts (all NULL, no invented times); documented backfill runbook maps each known cohort/module/project boundary to explicit starts with provenance (no deadline-minus-N inference).
  6. Studio + Admin API parity for every capability above (registry entries, OpenAPI, permissions, audit, redaction).
  7. CLI: inspect existing CLIs (deploy/cli.py is release-only — not an operator CLI); add operator CLI with named flags, --json/human output, stable exit codes, and AISL/DataOps-style auth (stored Bearer profile, login/logout/whoami, DATAOPS_TOKEN-style env override, 0600 perms). CLI covers templates/assignments/announcements/schedules/starts. No credentials in URLs.
  8. Safety: no public/real-user sends in dev — Relay dev sender courses allowlist/simulation only; controlled test-send to operator address only; Telegram adapter quarantines uncertain acknowledgement (no auto-retry of ambiguous).
Non-goals
  • No CMP changes in this issue (separate CMP starts worker owns legacy Homework/Project starts_at, API/CLI, import-boundary preservation).
  • No DataOps process-task extraction (separate worker).
  • No new distributed scheduler/celery beat; reuse community_base.jobs leased dispatch_after_commit(available_at) + Relay idempotency.
  • No self-paced schedules, deadlines, leaderboard, peer review, scores, certificates (spec 04 phase-one boundary).
  • No marketing/newsletter expansion beyond course launch announcements; no Slack-invite changes (§19 secret-at-send preserved).
  • No production sender/domain configuration, no broad recipients, no live sends.
Dependencies
  • Relay email boundary + EmailDelivery durable model (spec 05) — reuse, do not reimplement.
  • Course/Cohort + curriculum placement models (spec 04) — native starts attach here.
  • Capability registry + management_auth Bearer principals (spec 06) — CLI + API auth reuses these.
  • Blocked by: none for grooming/build (CMP starts contract coordinated in parallel; website must not duplicate CMP runtime).
Acceptance criteria
  • Templates: operator can create/edit/publish immutable versions of email + Telegram templates per kind; Course-create flow offers template assignment (defaults preselected, changeable); per-Cohort override works; seed content matches playbook copy-bank placeholders.
  • Announcements: operator can compose from template + cohort context with preview; announcement stays draft until explicit approve; approved announcement can be sent now or scheduled; scheduled announcement fires once via leased job + Relay idempotency key (no duplicates on retry).
  • Schedules: launching a live COHORT auto-creates durable schedule rows for each module/project START; rows are unarmed until operator approves/schedules; self_paced/github_archive cohorts create zero rows and their announce actions fail closed with a safe message.
  • Starts: every timing owner exposes offset-aware starts_at (null allowed); naive input rejected 400; start > end/deadline rejected; start edits never change deadlines; concurrent edits use revision/If-Match (stale → 409).
  • Migration: starts_at columns nullable; migration leaves all existing rows NULL; backfill runbook documents each explicit start + source/provenance; no inferred times; make migrate + drift check pass.
  • API/CLI parity: Studio + /api/v1/admin/ + CLI cover templates/assignments/announcements/schedules/starts with identical results; negative auth tests (no token / wrong scope / disabled principal → 401/403, no existence leak); idempotency-key replay returns same logical row; audit redacts bodies/secrets.
  • CLI auth: login/logout/whoami work against dev host; token stored 0600, env override works; --json on every command; --help with examples.
  • No-send safety: dev/test sends use only Relay sender courses allowlist/simulation; no Amazon SES/Datamailer path; Telegram uncertain-ack becomes quarantined/ambiguous, never auto-resent; test-send requires explicit operator destination + confirmation.
  • Permissions: course_operator (+ email_operator for send/test) enforced in Studio, API, CLI; support_operator sees masked PII only; all denials render safe messages (no stack/secret).
  • Empty/error states: no templates, no schedules, missing starts, past-due schedule, Relay unavailable, Telegram failure each render explicit operator guidance (no silent no-op, no 500 prose leak).
Django/integration scenarios
  • Live cohort launch → schedules exist per module/project START, all unarmed; approve one → leased job → single Relay idempotency key → one logical delivery.
  • Double-submit approve/schedule with same Idempotency-Key → one row/job; stale revision → 409.
  • Self-paced cohort launch → zero schedules; announce attempt → clean denial.
  • Migration on production-like copy → all starts NULL; backfill script applies documented explicit starts only.
Browser scenarios (desktop + mobile, tester captures both)
  • Studio course-create with template assignment; cohort-launch → schedule list (unarmed badge); announcement compose → preview → approve → schedule; past/missing-start rows show guidance, not broken layout.
  • Denied principal sees safe denial; unauthenticated Studio redirects to login.
Repository/operations scenarios
  • uv run --frozen python scripts/ci.py test-playwright-core (render impact) or smoke tier if backend-only, plus focused Django tests for changed contracts; migration-drift check; versioned verification plan with base/head + digests.
  • No .env/tokens/DB/screenshots committed; scratch under .tmp/; no live sends, secrets, or cloud mutations.
Roles
  • Engineer: launch-web (Codex, /home/alexey/git/dtc-website-wt-course-launch-system) — implement only after this grooming; leave worktree uncommitted/frozen for tester.
  • Tester: independent cross-engine — must pass before PM acceptance.
  • PM acceptance: after tester passes; checks UX, denials, empty/error states, API/CLI/core parity.
主要语言
Python
星标
0
派生
0
PR 合并指标
30 天内没有已合并 PR

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

DataTalksClub/website 的其他 Issue

查看 DataTalksClub/website 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。