DataTalksClub / DataTalksClub/website
Registration confirmation screen should prompt sign-up actions (Slack, Telegram, tweet, YouTube), like the old after-sign-up page did
Nobody has claimed this yet.
- 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_urlkeeps 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 incontent_sync/course_repository.py::_parse_course(strict allowed-field mapping,_https_urlvalidation 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 existingrow-listpattern 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
- Schema:
course.yamlgains two optional course-level fields,slack_urlandtelegram_url, siblings offaq_url; both validate as HTTPS URLs through the existing_https_urlparser idiom (/slack_url,/telegram_urlpointers). Existing files without them parse exactly as today. - Model:
Courseincourses/models/cohort.pygains the matching optional URL fields, one migration, and admin exposure following the existing course-field pattern. - Ingest:
content_syncmaps the newCourseSourcefields to the model and includes them in validation and replay identity exactly like existing course fields. - 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 hasslack_url(sitewide fallback otherwise). Row copy follows the existing title/description/CTA shape; the view passes the course links in context. - 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.mdfiles 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_urlincourse.yamlingests 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
- 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 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