Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの 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 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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 ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

DataTalksClub/website のほかの issue

DataTalksClub/website の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。