Creative brief for this page
Concept: every dev gets a ticket stub, like the ones at a college fest gate. Read your name, read your slice. Palette comes from MJCET's world: fog-grey notice boards, petrol-blue ink, and six stub colours so you can find yourself fast.
Assumptions: six developers (Ali, Amar, Syed Ayesha, Anas, Ayub and Adnaan). Stack suggestion is React + Node/Express + PostgreSQL + Socket.io; swap it if the team already agreed on something else. Real club logos and MJCET photos are needed from the club heads before launch.
Roles in the system
- Student: browses, RSVPs, joins live, sees recaps
- Club admin: registers a club, hosts events, approves people, runs the live room, builds the recap
- Super admin: approves new clubs (a handful of staff)
ReactExpressPostgreSQLSocket.ioMulter + S3 or CloudinaryJWT
Balance at a glance
Everyone carries the same load: eleven REST endpoints, six or seven pages, three or four tables, and one signature challenge. Foundations (auth, sockets, uploads) are split three ways.
| Dev | Endpoints | Pages | Tables | Signature challenge |
|---|---|---|---|---|
| Ali | 11 + 4 guards | 6 | 3 | Auth, guards, the RSVP capacity and waitlist engine |
| Amar | 11 + WebSocket gateway | 6 | 4 | Socket gateway, live quiz engine, live client state |
| Syed Ayesha | 11 | 7 | 4 | Event lifecycle state machine, discovery feed, live doubts board |
| Anas | 11 | 6 | 3 | Approval and payment workflow, event-day check-in, dynamic form builder |
| Ayub | 11 | 6 | 3 | Club approval workflow, upload service, design system |
| Adnaan | 11 | 6 | 4 | Recap aggregation, bulk gallery, certificate assignment |
The six slices
Counts are shown on every stub so you can check the split is fair.
Shared rules (agree on day one, 30 minutes)
One repo, six foldersBackend routes live in
/server/modules/<name>, pages in /client/src/features/<name>. Touch only your own folder; open a PR for anything shared.Response shapeEvery API returns
{ ok, data, error }. Errors carry a plain message the UI can show as is.Contract files firstBefore writing logic, every dev commits
/mocks/<endpoint>.json with a request and response example. UI is built against these until the real endpoint lands.Schema ownerAli runs the first migration with all 21 tables as stubs. After that, each dev edits only their own tables.
Status writesNobody writes
rsvps.status directly. Everyone calls Ali's rsvpService.transition(), so the capacity rule lives in one place.Peer review ringAli reviews Amar, Amar reviews Ayesha, Ayesha reviews Anas, Anas reviews Ayub, Ayub reviews Adnaan, Adnaan reviews Ali. Everyone reviews one person and is reviewed by one.
Who owns which table
| Table | Owner | Key fields |
|---|---|---|
| users, password_resets, rsvps | Ali | role, email, roll_no, branch, year; reset token and expiry; event_id, user_id, answers, status (pending, approved, rejected, waitlist) |
| quizzes, questions, quiz_answers, leaderboard_entries | Amar | quiz state, timer, correct option, points per answer, rank, manual points |
| events, event_settings, doubts, doubt_votes | Ayesha | club_id, capacity, approval_mode (auto_until_full or manual), is_paid, price, qr_url, status (draft, open, live, ended); upvote count, pinned |
| payments, checkins, rsvp_form_fields | Anas | rsvp_id, screenshot_url, verified_by, reject reason; checked_in_at; question label, type, required, order |
| clubs, speakers, uploads | Ayub | club status (pending, approved), owner_id; name, bio, photo, topic; file_url, mime, size |
| gallery_items, certificates, tech_links, recap_settings | Adnaan | event_id, file_url, caption, position; user_id, file_url; link title and url; published flag |
How nobody blocks anybody
| Dependency | Who needs it | Unblock rule |
|---|---|---|
| Migration, guards, JWT | Everyone | Ali ships the migration with all 21 tables as stubs and the guards with a fake-user mode by day 2. Ayub and Amar ship their own foundations in parallel. |
POST /api/uploads | Ayesha (QR), Anas (screenshots), Adnaan (gallery), Ayub (logos) | Ayub deploys a stub that returns a fake URL on day 1. The real implementation lands by day 4, with Ali reviewing. |
| Socket gateway | Ayesha (doubts) | Amar publishes emitToRoom(eventId, name, payload) as a no-op on day 2. |
| RSVP status transitions | Anas | Ali exports rsvpService.transition() as an interface first. |
| RSVP form schema | Ali's RSVP POST | Fix the JSON shape of rsvp_form_fields on day 1. Until then Ali uses a default form. |
| Room access | Amar | He calls requireApprovedAttendee from Ali, which returns true in mock mode. |
| Quiz scores | Adnaan | He reads GET /api/events/:id/leaderboard from /mocks until Amar's real one lands. |
If uploads slips: whoever has the lightest week picks up /api/uploads for the first week (about a day of work). Nothing else in the plan changes.
Timeline that avoids blocking
| Phase | What lands | Who unblocks whom |
|---|---|---|
| Days 1 to 3 | Repo, migration, auth, guards, upload stub, socket stub, design tokens, mock JSON for every endpoint | Ali, Amar and Ayub ship foundations. Others build UI against mock JSON in /mocks. |
| Days 4 to 8 | Club registration, host-event form, discover feed, RSVP flow, real upload service, RSVP form builder | Ayesha needs Ayub's club approval. Anas needs Ali's transition service and Ayesha's event detail. |
| Days 9 to 13 | Attendee approval queue, payment verification, check-in, live quiz with sockets, doubts board, recap page and gallery | Adnaan reads Amar's leaderboard and Ayub's speakers. Amar reads Ali's approved status for room access. |
| Days 14 to 16 | Integration, bug bash on one real club event, phone testing | Everyone. Pick one real club to test with. |