DataTalksClub / DataTalksClub/website

Registration confirmation screen should prompt sign-up actions (Slack, Telegram, tweet, YouTube), like the old after-sign-up page did

Open
#373 12 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

courses enhancement P2
Dominant language
Python
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Description

Summary

Complete the post-registration "what to do next" prompts with the per-course community links the old per-course after-sign-up.md files carried: the course Slack channel and the Telegram announcements channel. The sitewide slice already landed on main; what remains is the course.yaml/Course schema addition this issue flagged for grooming, plus the screen rows it feeds.

Grooming decisions

  • Per-course links: build the schema. There is no verified sitewide Telegram URL anywhere in the repository, and the historical Telegram channels were strictly per-course (t.me/<course-channel>), so optional per-course fields are the only faithful path.
  • Confirmation email: no community prompts. The screen is the moment; the email keeps its verify-email focus. This closes the "page, email, or both" question as page-only.
  • Display rules: when the course defines a Telegram link, the screen gains a Telegram row; when it defines a Slack link, the Slack row points at the course link instead of the sitewide one; tweet and YouTube rows stay sitewide. Absent links render no row and no empty state.
  • FAQ: stays out of scope. It is not one of the four prompts in the idea, and faq_url keeps its existing uses.

Already delivered on main (context; do not redo)

Commits 79999b43, 406442fd, ba34634c, beb950da landed the email-verification gate, the conditional verify-email row, and the sitewide Slack, tweet, and YouTube rows in courses/templates/courses/_registration_done.html, with coverage in courses/tests/test_registration_email_verification.py.

Normative references

  • Registration flow: _docs/specs/04-courses-and-cohorts.md (Registration section).
  • course.yaml schema and authoring: _docs/content-authoring.md; parser in content_sync/course_repository.py::_parse_course (strict allowed-field mapping, _https_url validation with JSON pointers).
  • Database-only public content: _docs/architecture/database-only-content.md. Per-course links are ingested course data rendered from model/context, not template constants; the sitewide rows already on main are site chrome.
  • Design system: _docs/design/design-system.md (the existing row-list pattern on the registration panel).
  • Process and verification: _docs/PROCESS.md, _docs/specs/10-verification-strategy.md, _docs/ci/change-selective-ci.md.

Scope and behavior

  1. Schema: course.yaml gains two optional course-level fields, slack_url and telegram_url, siblings of faq_url; both validate as HTTPS URLs through the existing _https_url parser idiom (/slack_url, /telegram_url pointers). Existing files without them parse exactly as today.
  2. Model: Course in courses/models/cohort.py gains the matching optional URL fields, one migration, and admin exposure following the existing course-field pattern.
  3. Ingest: content_sync maps the new CourseSource fields to the model and includes them in validation and replay identity exactly like existing course fields.
  4. Display: the registration confirmation screen's next-steps list adds a Telegram row when the course has telegram_url, and swaps the Slack row's target to the course link when it has slack_url (sitewide fallback otherwise). Row copy follows the existing title/description/CTA shape; the view passes the course links in context.
  5. No redirect, modal, or tracking behavior; the rows are plain links with the existing external-link conventions (target="_blank", rel="noopener noreferrer").

Non-goals

  • No community prompts in the confirmation email; the email changes nothing.
  • No per-course variants of the tweet, YouTube, or FAQ prompts.
  • No per-course tweet text; the existing share text stays.
  • No click analytics, join-state tracking, modals, or one-time dismissal.
  • No revival of after-sign-up.md files in course repositories.

Dependencies

None external. The change touches content_sync, courses (model, migration, admin, view, template), and focused tests.

Acceptance criteria

  • A course with slack_url/telegram_url in course.yaml ingests cleanly; the confirmation screen shows the Telegram row and the Slack row pointing at the course link, per the display rules.
  • A course without the fields ingests exactly as today, and its confirmation screen renders unchanged (sitewide Slack row, no Telegram row).
  • Non-HTTPS or malformed values fail ingest validation with the existing pointer-style messages.
  • Migration-drift check passes; admin lists and edits the new fields per the existing pattern.
  • Focused Django coverage covers ingest with and without the fields, the display rules, and the absence behavior; existing registration tests stay green.
  • Desktop and mobile rendering in light and dark keeps the next-steps list intact: rows wrap naturally, no overflow or overlap, new rows match the existing row pattern.
  • Engineer handoff and independent tester-final report bind the frozen base/head, verification-plan digests, and screenshot evidence per _docs/ci/change-selective-ci.md.

Meaningful verification scenarios

  • Django/integration: ingest a course fixture with and without the new fields; render the registration confirmation for both; assert the row replace/add/absent rules and ingest validation failures.
  • Browser (tester): a registrant's confirmation screen for a course with links and a course without, desktop 1440×900 and mobile 390×844, light and dark; external links carry the correct targets; screenshots under .tmp/screenshots/.
  • Repository/operations: the diff stays confined to the schema/parser, model/migration, admin, view, template, and their tests; no email template changes.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with content_sync/course_repository.py::_parse_course, courses/models/cohort.py, the existing migration/admin patterns, and courses/templates/courses/_registration_done.html; review the focused registration tests before changing anything. Done means optional HTTPS links ingest with and without fields, Slack and Telegram rows follow the stated rules, validation and migration checks pass, and focused plus rendering verification covers the acceptance criteria.

Written by the indexing model from the issue text.

Assessment

Tech stack
django, python, yaml
Domain
full-stack
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.